AO-Aitt  Aft  STANTPNO  UNIV  CA  OCPT  OF  COMFUTCR  tCtCNCE  F/0  f/f 

ON  FROONAM  TRANSFiMMATlONf  FOR  ARfTRACT  DATA  TYFCS  AND  CONCURRC— CTC(U> 
OCT  01  F  FCFFCR  NOOOIA-TO-C-OMT 

MNCLASSXFieO  STAN-CO-tl-Ma  NL 


ADA  1 1 


October  1981 


Report.  No.  STAN'CS'81'883 


X'  '  { 


Oi\  Program  Transformations  for  Abstract 
Data  Types  and  Concurrency 

by 


P.  Pepper 


/*  /V  7 ' 

Department  of  Computer  Science 


Stanford  University 
Stanford,  CA  94305 


piSTRIBUTIONj  L'l-'L'iLii'' 'iLA 
’"Approved  for  pui/do  r.  leoset 

Distribution  Unlimited _ _ 


DTIC 

ELECTEI^^ 

MAR  2  6  1982  ' 

B 


5 


v>  V 


On 

Program  Transformations 
for 

Abstract  Data  Types 
and  Concurrency 

by 

P.  Pepper 

Computer  Science  Department 
StaiiTord  University 
Stanford,  Ca  91305 


Abstract 

’  We  stiuly  transformation  rules  for  a  particular  cljiss  of  abstract  data  types,  namely  types  that  are 
representable  by  recursive  inode  declarations.  The  transformations  are  tailored  to  tbe  development 
of  cilieient  tree  traversal  and  they  .allow  for  concurrency.  'I'he  techniques  are  ('xemplified  by  an 
implementation  of  concurrent  insertion  and  deletion  in  2-3-trcc3. 


This  rcsc;iri-h  h;is  been  siipporlnd  by  Ibo  OviiLtclw  l^'or!lcllllllg.•^|'crn<.■inxrll:lfl  and  by  Ibc  Olllcc  of  Naval  Ki-soarcb 
iindi  r  (.’ontracl  N()OOH-7G-C-()G87. 


I 


1.  Data  Types,  Transformatios  and  Concurrency 

The  purpose  of  this  study  is  threefold;  We  seek  transformations  for  data  structures.  We  want  these 
transformations  to  allow  for  concurrency.  And  we  want  to  apply  them  to  a  nontrivial  example, 
viz.  concurrent  operations  on  data  bases.  We  do  not  talk  here  about  notations  for  transformations 
nor  do  we  discuss  their  automatic  application.  And  we  avoid  detailed  semantical  considerations 
(which  arc  replaced  by  references  to  the  pertinent  literature). 

Program  transformations  shall  capture  frequently  employed  programming  tcchnicpies  be  they 
newly  invented  or  taken  from  the  literature  -  into  a  schematic  form  that  allows  a  fairly  easy 
application  to  concrete  problems.  It  usually  does  not  make  sense  to  aspire  to  rules  that  are 
applicable  to  any  program' .  One  rather  has  to  concentrate  on  special  classes  of  programs  to  achieve 
reasonably  powerful  and  flexible  tran.sformations  (e.g.  recursion  removal,  loop  optimization,  etc.). 
For  this  reason  we  focus  on  the  particular  class  of  those  data  structures  which  arc  defined  by 
recursive  mode  declarations.  The  transformations  presented  include  the  derivation  of  traversal 
operations  and  of  pointer  implementations. 

Concurrency  is  viewed  here  as  an  optimization  issue  rather  than  as  an  inherent  property  of  the 
given  problem.  This  view  is  certainly  admissible  when  the  concurrency  comes  into  existence  by 
allowing  several  processes  to  execute  a  known  sequential  task  simultaneously.  In  this  case  it  is  also 
appropriate  to  work  with  the  so-called  multiprogramming  assumption,  i.c.  to  semantically  model 
parallelism  as  sequential  interleaving  of  atomic  actions. 

Data  base  operations  such  as  insertion,  removal  and  search  meet  the  above  ro((uiroments.  These 
operations  are  well-known  in  sequential  applications  and  they  arc  now  to  be  transferred  into 
concurrent  environments.  For  the  implementation  of  data  bases  one  frequently  uses  tree  structures, 
for  example  the  ll-trces  suggested  in  [-1].  To  shorten  the  writing-down  we  will  restrict  ourselves  to 
the  special  case  of  2-3-troes  (cf.  [1]). 

The  pa|)er  has  two  major  parts.  Section  3  lists  a  number  of  transformations  for  recursive  data 
structures.  These  transformations  essentially  capture  standard  programming  tcchni<iues  within  the 
formalism  of  abstract  data  types  and  also  make  an  attempt  to  cope  with  concurrency  and  protection 
problems.  The  use  of  abstract  data  types  leads  to  a  valuable  accuracy  of  the  specilii:atio,,s.  Hut 
one  has  to  pay  a  price,  viz.  an  increased  length  of  co<le.  (This  makes  the  generation  of  abstract 
data  types  by  transformations  even  more  dc,sir;iblc.)  I'/Vcn  if  we  restrict  our  attention  to  the  cl.ass 
of  recursive  type  declarations  there  remains  a  vast  abundance  of  conceivable  transformations.  The 
choice  made  in  this  paper  is  primarily  motivated  by  the  intended  sample  development.  Hut,  vice 
versa,  the  design  of  the  algorithm  is  also  innucnced  by  observations  about  the  available  rules  - 
an  interesting  feedback  between  transformations  a’-  1  decision  making  on  the  programmer’s  side. 

Section  d  contains  a  development  of  the  oper;  •  'sert  and  remove  for  2-3-trees,  allowing  for 
concurrency.  The  algorithm  dilTcrs  somewhat  Irom  ■  one  given  in  [1]  and  its  improved  version 
in  111).  'Phis  dilTerence  may  be  roughly  <lescribed  as  follows;  H-trccs  as  well  as  their  special  c.asc 
2-3-lree.s  have  two  characterisitc  properties,  viz.  the  special  tree  structure,  which  is  responsible 
for  the  correctness  of  all  operations,  ami  the  balancing  (all  paths  have  the  same  length),  which  is 
responsible  for  the  efficiency.  The  operations  in.serl  an<l  remove  at  least  temporarily  violate  these 
properties.  In  [-11  the  decision  was  to  violate  the  particular  tree  structure  and  to  keep  the  balancing 
intact.  We  feel,  however,  that  the  correctness  issue  rieserves  [)recedenco  and  therefore  keep  the 

'Well,  coinpilors  .ire  an  exception. 
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tree  structure  intact  while  tolerating  a  temporary  disturbance  of  the  balancing.  As  a  consequence, 
locks  arc  only  needed  for  a  very  few  nodes  at  a  time  and  reading  as  well  as  writing  operations  may 
almost  unrestrictedly  coexist  H  the  same  (sub)trees. 

There  is  one  severe  problem:  Transformations  ought  to  be  “correct”.  But  any  notion  of  correctness 
is  vain  without  a  precise  semantical  definition  of  the  language  under  consideration.  Our  topics  here 
are  abstract  data  types  and  concurrency,  both  issues  that  are  currently  attacked  (with  varying 
success)  in  an  abundance  of  articles.  It  clearly  is  far  beyond  the  scope  of  this  paper  to  discuss  two 
such  heavy  problems  incidentally.  We  will  therefore  nolens  volens  rely  on  a  more  intuitive  idea 
of  the  correctness  of  transformations.  The  focus  of  our  attention  will  be  the  technical  feasibility 
and  the  usability  of  the  rules,  assuming  that  they  are  semantically  justified.  (It  will  only  be  in  the 
appendix  that  we  try  to  at  least  sketch  the  underlying  semantic  modelling.) 

2.  The  Basic  Problem 

The  problem  domain  we  have  chosen  allows  a  clear  partitioning  into  two  subtasks:  The  operations 
to  be  performed  on  the  given  data  structure  arc  specified  completely  independently  from  any  con¬ 
currency  considerations.  The  parallelism  comes  in  by  simply  allowing  several  sequential  processes 
to  operate  on  the  common  data  structure  simultaneously.  The  situation  is  therefore  characterized 
by  the  fact  that  the  the  processes  communicate  for  no  other  reason  but  protection  against  mutual 
interferences. 

2.1.  The  Data  Type  dictionary 

In  a  very  abstract  form,  data  bases  may  be  thought  of  as  sets  on  which  the  basic  operations  “insert 
an  element”,  “find  an  element”  and  “remove  an  clement”  can  be  performed.  These  operations  arc 
formally  specified  by  the  following  abstract  data  type  DICTIONARY  (as  it  is  termed  in  [1]).  The 
notation  will  be  explained  below. 

type  DICTIONARY  (type  ELEM)  declares  set, insert, remove, member  : 

based  on;  ELEM,  BOOL 
sorts:  set 

opns:  empty  ;  elem  — »  set 

insert  :  set  x  elem  — >  set 

remove  :  set  x  elem  — ►  set 

member  :  set  x  elem  —*  bool 

axioms:  Vsets,  elemx,y  : 

member(empty  ,y)  ^  false 

member(insert(s,  x),y)  -  true 

”  member  (s,y) 
remove(insert(s,  x),y)  —  remove(s,y) 

-  insert(remove(s,y),  x) 

required:  V  elem  x  : 

s  empty  for  remove(s,  x) 

end  of  type 
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The  notation  used  here  is  a  syntactically  sugared  mixture  of  those  found  in  [7]  and  [13]:  The 
parainetrization  takes  into  account  that  sets  can  be  defined  for  any  type  of  elements.  As  suggested 
by  the  keyword  declares^  a  number  of  identifiers  are  provided  to  the  environment;  all  functions  not 
listed  here  are  “hidden”.  (Thus  the  operation  empty  is  hidden.  Actually,  without  this  operation 
it  is  impossible  to  generate  an  initial  set  for  further  use.  Hut  we  assume  that  there  is  some 
mechanism  such  as  the  ADA  package  initialization,  which  is  of  no  concern  to  us  here.  We  deal 
only  with  processes  that  arc  allowed  to  use  the  remaining  operations  on  an  existing  set.)  The  type 
is  based  on  two  other  types,  viz.  the  parameter  ELEM  and  BOOL,  and  it  introduces  a  new  sort 
of  objects,  called  sets.  The  list  of  operation  symbols  together  with  their  functionalities  completes 
the  “syntactic  interface”. 

The  axioms,  a  set  of  universally  quantified  conditional  equations,  specify  the  behavior  of  the 
operations  and  objects  defined  by  the  type.  The  requirements  play  a  particular  role:  It  is  understood 
that  all  other  ccpiations  only  hold  if  none  of  the  requirements  is  violated  (“implicit  condition”).  In 
the  literature  one  finds  essentially  two  ways  of  handling  partially  defined  functions  such  as  remove. 
One  is  to  introduce  special  error-elements.  In  this  setting  we  would  write 

V  set  s,  elem  X  :  remove  (s,  x)  =  error  if  s  =  empty. 

Alternatively,  one  may  work  with  partial  algebras,  which  leads  to  notations  such  as 

Vsets,  elem  X  :  undefined(remove(s,  x))  if  s  =  empty, 
or  equivalently 

Vset  s,  elem  x  :  s  empty  if  defined(remove(s,  x)). 

For  some  of  the  applications  in  this  paper  the  last  form  will  be  the  most  convenient  one  for 
expres.sing  the  restriction  of  the  domain  of  a  function.  To  stress  this  particular  usage  we  employ 
the  special  notation^ 

Vset  s,  elem  x  :  s  empty  for  remove(s,  x). 

From  our  practical  point  of  view  we  need  not  care  about  the  two  (theoretically  quite  different) 
pos.sible  interpretations  of  partially  dofine<l  functions. 

In  later  examples  we  will  use  some  further  constructs.  'I'he  expression  enrich... by  instead  of 
based  on...  means  that  we  only  add  new  operations  to  the  type,  hut  that  these  operations  do 
not  generate  further  objects.  As  pointed  out  by  Ihirstall  and  (loguen  (cf.  [7])  this  allows  the  use 
of,  s;iy,  existential  quantifiers  in  enrichments.  Finally,  the  expression  A  ©  B  builds  the  “disjoint 
union”  of  the  types  A  and  B  except  that  common  subtypes  are  not  duplicated. 

According  to  the  principles  described  in  |I3]  or  [5|  any  model  of  this  data  type  is  acceptable  as 
an  ir,n|)lementation.  Though  never  making  explicit  use  of  it  we  will  oriei\t  our  whole  development 
towards  the  so-called  “terminal  tnodel”.  Without  going  into  any  theoretic.al  details  this  model 
may  be  roughly  characterized  by  the  following  definition  of  the  equality  of  its  objects.  'I'he  only 
way  to  distinguish  two  sots  “from  the  outside”  is  by  checking  their  elements  using  the  operation 
member.  This  means  that  two  sets  s  and  s'  are  “indistinguishable”  or  “visibly  equivalent”  if 
for  all  X  the  erpiality  member(s,x)  ■=■  member(s', x)  hohls.  When  aj^plying  this  criterium  to  tree 
implementations  we  have  to  consider  two  trees  as  being  equivalent  if  they  have  the  same  leaves 
(even  though  they  may  exhibit  completely  different  intern.al  structures). 


’Spccirii'alion  languages  exhiliil  a  tendency  towards  colloquialism. 
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2.2.  Concurrency 


The  second  major  aspect  of  our  task  is  concurrency:  Tiierc  are  several  proce.sses  performing  the 
above  operations  on  the  given  set  simultaneously.  For  the  protection  of  these  processes  against 
mutual  interferences  when  accessing  the  common  set  s  we  employ  a  locking  mechanism.  The 
operation  r-lock(s)  sets  a  read-lock  on  the  variable  s  and  the  oj)eration  w-lock(s)  sets  a  wntc-lock. 

Our  program  consists  of  n  processes  executing  set  operations  of  the  kind 

|[  ...  r-lock  (s);  b  member(s,  x);  r-unlock  (s); 

II  P„::  . . .  w-lock  (s);  s  insert(s,  x);  w-unlock  (s);  ...  ||  ...  | 


In  the  above  specification  of  l.he  concurrent  proce.sses  and  their  inter;iction  the  operations  insert, 
removeand  member  are  taken  to  be  “atomic”.  This  is,  of  cour.se,  unrealistic  and  therefore  the 
go;il  of  the  sulisctiuent  prr)gram  development  will  be  to  increase  the  degree  of  concurrency  by 
implementing  tbese  operations  in  terms  of  more  elementary  ones. 


3.  Techniques,  Tools  and  Transformations 


'I'he  underlying  idea  of  program  transformation  is  to  capture  repeatedly  occurring  programtning 
technicpies  in  schemal.ic  rub's  such  that  it  becomes  fairly  ('asy  to  apply  these  tc'chnicpies  to  concrete 
problems.  l''or  classic.-il  language'  constructs  (recursive  functions,  loops,  assignmi-nis  (-Ic.)  pairs  of 
program  schemata  have  already  proved  good  (cf.  e.g  j(i]),  but  in  connection  with  data  structures 
and  their  ojeerations  the  task  becomes  more  complex.  We  will  try  bore  to  attack  the  issue  within 
the  framework  of  abstract,  data  types. 

Systems  such  as  CLEAR  or  ODJ  (cf.  [7j,  [S|)  provide  valu.able  tools  for  modularizing  a  devi'lopment 
process  and  for  <lescribing  relationships  between  various  typos.  (In  addition  they  are  ba.sed  on 
a  sound  mathematical  theory.)  However,  the  systems  of  types  are  still  “static”,  i.e.  fixed  upon 
writing-down.  A  stepwise'  |)rogram  development  proeess  also  needs  a  dynamic  compom  til,,  i.e.  tools 
for  altering  given  type  systems.  Transformations  a"e  such  a  dynamic  tool.  We  are  not.  attempting 
to  cast  the  transformations  presented  in  this  chapter  into  a  form.-d  tiotation.  The'  paper  should 
rather  be  see'ii  as  a  test  whether  the  development  of  such  a  formalism  sec'rns  worthwhile. 

We  try  here  to  identify  those  transform.'itions  that  are  needed  to  achieve  a  particular  goal,  viz. 
tree  operations  that  can  do  without,  exh.'iustive  search.  Therefore  W('  develoj)  specialized  abstract 
data  types  that,  contain  just  the  properties  we  need.  'I'hese  properties  art'  found  by  analysing 
algoritluns  known  from  the  literature  ami  by  separating  their  es.sential  characterisitics  from  minor 
particularities. 


3.1.  Recursive  Type  Declarations 

There  is  a  particular  class  of  abstract  data  types  that  are  both  easily  understood  and  frequently 
occurring  in  applications.  In  fact,  due  to  their  simplicity  these  types  are  usually  written  in  the 
shorter  notation  of  recursive  inode  declarations.  A  classical  example  arc  binary  trees: 

type  tree  ^  leaf  (elem  item )  |  cons  (tree  son  1,  tree  son2) 


This  can  be  viewed  as  a  shorthand  notation  for  a  type  TREE  that  introduces  in  addition  to  the 
operations  leaf,  item,  cons,  sonl  and  son2  with  their  obvious  axioms  also  the  test  functions 
.  is  leaf  and  .  is  cons  (cf.[3]). 

Because  of  its  shortness  we  will  from  now  on  work  with  this  example,  but  it  should  be  understood 
that  the  techniques  apply  to  any  type  that  is  denned  by  such  a  recursive  declaration  involving 
direct  product  and  direct  sum.  In  this  sense  the  subsequent  sections  should  be  seen  as  presenting 
rules  that  apply  to  arbitrary  recursively  defined  data  types. 

A  note  of  caution:  If  a  tree  contains  two  identical  subtrees  the  specification  allows  implementations 
according  to  cither  of  the  following  figures: 


So  one  has  to  be  careful  when  applying  arguments  that  intuitively  refer  to  the  left  model.  The 
sub.scquent  considerations  work  for  both  cases,  but  in  general  it  is  recommciidable  to  use  trees 
without  multiple  subtrees. 

We  are  aiming  at  a  particular  class  of  algorithms,  namely  those  that  traverse  trees  elliriently 
without  the  need  for  exhaustive  searches  such  as  depth-first  or  breadth-first  search.  Therefore 
we  assume  that  there  exists  a  predicate  P  that  determines  for  any  given  tree  whether  the  search 
should  continue  in  the  left  or  in  the  right  son.  (This  special  case  is  the  one  we  are  interested  in 
and  for  which  we  therefore  formulate  a  transformation.)  To  expre.ss  this  special  goal  we  introduce 
an  enrichment  of  the  type  TREE  that  reflects  the  property  that  P  is  true  for  exactly  one  son  if  it 
is  true  for  the  father. 


type  PTREE  declares  P  : 

enrich  TREE  by 

opns;  P  :  tree  — »  bool 

required:  V  tree  t,  : 

(P(sonl  (t))  V  P(son2(t)))  -  true  if  t  is  cons  A  P(t)  ”  true 

(P(sonl(t))  A  P(son2(t)))  =  false  if  tis  cons  A  P(t)  «  true 

end  of  type 
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Tlic  generation  of  this  type  could  be  done  automatically  by  some  of  the  later  transformations.  But 
the  presentation  is  more  straightforward  if  we  do  it  right  here,  for  this  indicates  that  the  whole 
development  relies  on  the  existence  of  such  a  P. 


3.2.  Subtrees  and  Substitution 

Basic  notions  for  trees  are  the  predicate  “is  subtree  of”  and  the  operation  “within  t  substitute  s  by 
u”.  For  easier  readability  we  will  use  the  infix  notations  s  ^  t  for  the  subtree  relation  and  t[s  <=  u] 
for  the  substitution  operation.  Both  can  be  defined  by  a  simple  data  type  extension.  (Note  that 
substitute  replaces  all  occurretices  of  s  within  t  and  that  the  restriction  for  the  substitution  is 
induced  by  the  type  PTREE.) 

type  TREE‘S  declarea  .  ,  .[.♦=.); 

enrich  PTREE  by 

opns:  •  ‘  tree  x  tree  — ►  bool 

.[.<=.];  tree  x  tree  x  tree  — +  tree 

axioms;  V  tree  s,  t,  u  : 

s  ^  t  =  true  if  s  =  t 

“  true  if  t  is  cons  a  (  s  sonl  (t)  v  s  son2(t) ) 

=  false  otherwise 

t[s  ^  u]  =  u  if  t  =  s 

=  cons (  son l(t)[s  <=  u] ,  son2(t)[s  u] )  if  t7«sAtiscons 
“  t  otherwise 

required:  Vtreet,  u: 

P(t)  <=>  P(u)  for  t[t  uj 

end  of  type 


Now  assume  that  wo  have  operations  that  transform  trees  into  trees.  As  a  running  example  we 
will  use  the  .addition  of  a  leaf. 

type  TREEl  declares  add  : 

enrich  PTREE  by 

opns:  add  :  tree  x  elcm  — ►  tree 

axioms;  V  tree  s,  elem  y  : 

add(s,y)=>s  if  item(s)-=y 

-  cons(s, leaf(y))  otherwise 

required:  V  tree  s,  elem  y  : 

s  is  leaf  for  add(s,y) 

end  of  type 
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The  leaf  to  which  the  operation  add  shall  be  applied  is  in  general  contained  in  some  enclosing 
tree.  Therefore  we  need  an  extension  Add  that  applies  add  to  a  suitable  subtree  of  a  largo  given 
tree.  The  problem  here  lies  in  the  word  “suitable”:  Since  the  restrictions  above  do  not  determine 
an  admissible  subtree  uniquely  we  have  to  make  a  choice.  Making  choices  means  to  introduce 
nondeterminisrn.  Within  the  classical  framework  of  abstract  data  typos  the  only  way  of  doing 
this  is  by  way  of  disjunctions  and  existential  quantifiers.  (l''or  more  details  see  appendix  A.)  The 
following  type  therefore  specifies  that  the  addition  should  take  place  at  any  subtree  s  of  t  which 
is  a  leaf.  (Note:  If  s  occurs  several  times  in  t  the  new  leaf  is  added  several  times;  but  in  our 
aforementioned  equivalence  relation  this  docs  not  matter.) 


type  EXTENDED  TREE  declares  Add  : 

enrich  TREE+  ©  TREEl  by 

opns:  Add  :  tree  x  elem  — ♦  tree 

axioms:  V  tree  t,  elem  y,  3  tree  s  : 

s  ^  t  A  s  is  leaf  a  Add  (t,  y)  =  t[s  ^  add(s,  y)] 

end  of  type 


This  type  illustrates  a  typical  aspect  of  transformation  systems.  Certain  rules  arc  designed  in 
a  relatively  complicated  fashion  to  ensure  correctness  in  any  case.  But  they  will  only  effect 
improvements  when  applied  to  programs  exhibiting  special  properties.  In  our  case  this  means  that 
the  above  transformation  is  best  applied  in  those  cases  where  the  restrictions  of  the  Ly|)e  TREEl 
dctcrttiine  the  subtree  uniquely. 

Transformation:  The  transformation  has  the  form  MAKE-EXTENDED-TREE(TREE, TREEl), 
where  TREE  refers  to  (some  enrichment  of)  a  recursive  type  and  TREEl  specifics  the  special 
operations  such  as  add.  The  result  is  a  type  of  the  kind  EXTENDED  TREE. 

The  transformation  is  indeed  mechanically  performable,  since  all  parts  of  the  equations  are  syntac¬ 
tically  derivable  from  the  given  types.  In  particular,  the  condition  in  the  type  EXTENDED  TREE 
is  just  the  requirement  for  the  operation  add,  i.e.  the  substitution  is  applied  at  some  permissible 
point. 

If  we  make  corresponding  enrichments  for  deletion  and  membership  test  (see  section  '1)  this  type 
provides  an  implementation  for  the  type  DICTIONARY.  To  show  this  one  needs  an  ctpiivalcnce 
relation  on  trees  (cf.  [5]).  The  appropriate  one  here  is:  Two  trees  tj  and  t2  arc  equivalent  if  they 
have  the  same  set  of  leaves.  (The  internal  structure  of  the  trees  as  well  as  the  multitude  of  leaves 
are  neglected.)  Using  this  relation  we  could  prove  that  all  .axioms  of  the  type  DICTIONARY  arc 
fiillilled  by  the  implementation.  As  a  matter  of  fact,  the  resulting  model  is  the  terminal  one,  since 
the  e()uivalencc  coincides  with  the  visible  equivalence  of  DICTIONARY. 

1’his  will  be  the  only  point  in  a  program  development  along  the  lines  described  here,  where  one 
needs  proofs  on  a  meta-level  (employing  c(juivalence  relations,  homomorphisms  and  the  like),  l-'rom 
then  on  the  development  can  make  use  of  the  transformations  to  be  presented  below. 
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3.3.  Tree  Traversal 


Though  being  very  convenient  for  specification  purposes  —  e.g.  for  the  proof  that  the  type 
EXTENDED  TREE  is  an  irnpicmentation  of  the  type  DICTIONARY  the  above  notion  of  “.subtree” 
does  not  indicate  how  the  subtree  may  be  localized  in  an  cIRcient  way.  To  get  a  more  operational 
specification  that  describes  “tree  traversal”  we  introduce  the  idea  of  a  “current  node”  into  our  types. 
(We  will  use  the  terms  “current  node”  and  “current  {.sub)trce”  synonymously.)  Conceptually  this 
may  be  specified  by  a  pair  of  two  trees  one  of  which  is  a  subtree  of  the  other. 

The  predicate  P  introduced  in  the  type  PTREE  of  section  3.1  is  now  used  to  direct  the  search 
through  the  tree.  For  this  reason  the  subsequent  type  is  based  on  PTREE. 

type  TRAVERSABLE  TREE  declares  ttree, reset, down  , up, current  : 


enrich 

PTREE 

by 

sorts: 

ttree 

opns: 

init  : 

tree 

ttree 

reset  : 

ttree 

-+ 

ttree 

down  : 

ttree 

-♦ 

ttree 

up  : 

ttree 

ttree 

root  : 

ttree 

-► 

tree 

current 

ttree 

-► 

tree 

axioms:  V  ttree  tt,  tree  s  : 

root(init(s))  =■  s 

root(reset(tt))  ~  root{tt) 
root(down(tt))  =  root(tt) 
root(up(tt))  =  root(tt) 

current(reset(tt))  =  root(tt) 

current(down  (tt))  =  soni(current(tt))  if  P(soni(current(tt)))  =  true 
up(down(tt))  =  tt 

required:  V  ttree  tt : 

current(tt)  root(tt) 

P(current(tt))  -  true 

current(tt)  root(tt)  for  up(tt) 

-’(current(tt)  is  leaf)  for  down(tt) 

end  of  type 

Note  that  the  operations  init  and  root  are  hidden,  i.e.  any  process  working  with  the  type  can  only 
use  the  operations  reset  etc.  (As  in  the  type  DICTIONARY  we  assume  some  kind  of  initialization 
mechanism.)  The  operation  up  is  only  specified  ;is  being  the  inverse  of  down.  Note  also  that  the 
first  two  requirements  hold  by  construction.  Hut  they  will  become  important  in  a  later  e.xtcnsion. 

As  a  straightforward  extension  we  now  add  the  operation  “substitute”  in  such  a  way  that  it  is 
automatically  applied  to  the  current  subtree. 

type  TRAVERSABLE  TREE+  declares  subst  : 

enrich  TRAVERSABLE  TREE  ®  TREE'*'  by 

opns:  subst  :  ttree  x  tree  — »  ttree 
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axioms:  V  ttree  tt,  tree  s  : 

root(subst(tt,  s))  -  root(tt)|current(tt)  <=  s] 

current(subst(tt,  s))  —  s 

required:  V  ttree  tt,  tree  s  : 

P(s)  =  true  for  subst(tt,  s) 

end  of  type 

The  requirement  is  enforced  by  the  type  TRAVERSABLE  TREE:  The  predicate  P  has  to  be 
invariantly  true  for  the  current  subtree. 

Transformation:  In  the  transformation  MAKE-TRAVERSABLE-TREE(TREE,P)  the  parameter 
TREE  again  refers  to  (some  enrichment  of)  a  recursively  defined  type  and  P  is  the  predicate 
for  directing  the  search.  The  re.sult  of  the  transformation  is  the  type  TRAVERSABLE  TREE'^ 
(including  the  type  PTREE,  which  may  be  automatically  g;cncratcd  here). 

Note  that  the  only  references  to  the  underlying  recursive  type  are  the  use  of  son^  and  the  predicate 
isleaf  in  the  specification  of  down  .  Therefore  the  transformation  is  indeed  mechanically  executable. 


3.4.  Implementing  Substituion  by  Tree  Traversal 

The  type  EXTENDED  TREE  uses  a  complex  substitution  operation  that  applies  to  all  subtrees 
having  a  certain  property.  The  purpose  of  tree  traversal  is  to  localize  such  subtrees,  i.e.  to  tnake 
them  into  current  trees.  If  no  further  information  exists  this  traversal  has  to  follow  a  depth-first 
search  or  a  breadth-first  search  strategy.  We  will,  however,  formulate  a  transformation  for  the 
case  where  the  subtree  can  be  uniquely  determined  using  the  predicate  P  mentioned  in  section  3.3. 

In  section  3.2  wo  have  enriched  the  biisic  type  TREE  by  special  operations  such  as  add.  As 
an  intermediate  step  we  do  the  same  enrichment  for  traversable  trees,  now  applying  the  opera¬ 
tion  to  the  current  subtree.  Hence,  tl’.-'  new  operation  shall  have  the  property  add'(tt, y)  = 
subst(tt,  add(current(tt),y)),  which  according  to  the  definition  of  the  original  add  leads  to  the 
specification® 

type  TRAVERSABLE  TREEl  declares  add  : 

enrich  TRAVERSABLE  TREE  by 
opns:  add  :  ttree  x  elem  -+  ttree 

axioms:  V  ttree  tt,  elem  y  : 

add(tt,y)  =  tt  if  item  (current(tt))  =>  y 

=  subst(tt,  cons (current(tt),  leaf (y)) )  other-wise 

required:  V  ttree  tt,  elem  y  : 

current(tt)  is  leaf  for  add(tt,y) 

end  of  type 

The  following  type  combines  the  above  substitution  with  the  tree  traversal  that  finds  a  suitable 
subtree.  (Note  that  the  predicate  P  is  part  of  the  definition  of  down.) 


’The  iiso  of  the  same  idonlificr  docs  no  harm  since  the  environment  always  distinguishes  them. 
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type  EXTENDED  TRAVERSABLE  TREE  declares  Add  : 

enrich  TRAVERSABLE  TREEl  by 
opns:  Add  :  ttree  x  elem  — »  ttree 

axioms:  V  ttree  tt,  elem  y  : 

Add(tt,y)  “  Add  (down  (tt),y)  if  -•(  current(tt)  is  leaf  ) 

Add(tt,  y)  “  add(tt,  y)  if  current(tt)  is  leaf 

end  of  type 

It  is  clear  how  in  a  procedural  version  of  the  program  the  function  Add  wouhl  hecotiie  a  simple  loop. 
'I'lie  important  question  is,  however,  under  which  conditions  the  above  operation  Add  im[)leinents 
the  one  in  section  il.2  (where  impleimuitation  means  that  it  yields  one  of  the  results  contained 
in  the  nondeterministic  choice).  In  other  words,  when  does  the  predicate  P  lead  to  a  subtree  s 
compatible  with  the  restrictions  for  add  in  the  type  TREEl? 

Let  R(s)  stand  for  the  restriction,  in  our  case  R(s)  =“sisleaf”.  'I'hcn  the  applicability  condition 
for  the  transformation  is 

V  t :  ^P(son  ,(t))  A  (3  s  :  s  t  A  R(s))^  ^3  s  :  s  son  ,(t)  A  R(s) 

or  in  prenox  form 

V  t,  s  :  3  s'  :  (s  t  A  R(s)  A  P(son  i(t)))  =»  (s'  •;<  son  ,(t)  A  R(s')) 

This  mc'ans  that  if  there  exists  an  admi.ssible  subtree  at  all  then  there  must  be  one  on  the  chosen 
path.  I'or  the  particular  predicate  s  is  leaf  of  our  example  this  is  trivially  true  for  arbitrary 
predicates  P. 

Transformation:  MAI<E-EXTENDED-TRAVERSAnLE-TREE(PTREE, TREEl)  uses  (some  enrich¬ 
ment  of)  the  basic  recursive  type  TREE  together  with  the  predicate  P  and  the  special  operation 
add  defined  in  TREEl  to  produce  the  type  EXTENDED  TRAVERSABLE  TREE  (including  the  typo 
TRAVERSABLE  TREEl),  provided  that  the  above  applicability  condition  is  met. 

Again  the  transformation  only  uses  syntactic  information  av.ailable  from  the  two  given  types  to 
construct  the  new  one.  Hence  it  can  be  realized  mechanically  (c'xccpt  for  the  checking  of  the 
ap|)licability  condition.) 

There  are,  of  course,  variants  of  this  transformation.  In  particular,  the  search  for  an  admissible 
subtree  need  not  start  at  the  root  (using  the  operation  reset)  but  may  begin  at  the  current  subtree, 
since  after  the  execution  of  one  operation  it  is  frecpiently  known  that  the  subse(|uent  one  will  be 
applicable  in  the  immediate  vicinity  (cf.  appendix  A). 

'I'he  state  we  have  reached  by  now  is  as  follows: 

Under  the  assumption  that  the  earlier  (nondeterminislic)  type  EXTENDED  TREE  indeed  imple¬ 
ments  the  original  type  DICTIONARY  the  .above  type  EXTENDED  TRAVERSABLE  TREE  is  an 
implementation,  too.  (insert(s,x)  corresponds  to  Add  (reset(s),  x)  ).  All  the  user  has  to  do  to 
generate  this  type  is  to  give  the  initial  recursive  decl.aration  of  trees,  the  predicate  P  and  the 
special  operation  add.  I'he  rest  is  achieved  by  the  transformations. 
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3.5.  Implementing  Trees  by  Pointer  Structures 


A  standard  technique  for  implementing  trees  is  to  use  pointer  structures  in  some  kind  of  “store” 
-  be  it  disk  storage,  the  central  memory  or  an  array.  Since  we  want  to  stay  within  the  framework 
of  abstract  data  types  we  have  to  uiimic  this  concept  of  a  store  by  specifying  a  mapping  that 
associates  names  (“indices”,  "addrc.sscs”,  “references”)  to  values.  The  situation  is  very  much  the 
same  as  for  “recursion  removal”  in  classical  transformation  systems.  One  does  not  go  all  the  way 
to  loops  but  only  changes  the  kind  of  recursion  from,  say,  nested  recursion  to  tail  recursion.  The 
direct  correspondence  between  the  latter  and  loops  is  taken  for  granted.  Thus  one  can  stay  within 
the  framework  of  applicative  ''ormulations  and  still  approaches  an  operationally  motivated  goal. 

As  a  further  advantage  of  an  abstract  view  of  a  store  we  need  not  distinguish  between  developments 
aiming  at  pointers  (as  is  possible  in,  say,  PASCAL  or  ALGOL68)  or  at  arrays  (as  is  neccsssary  in 
FOIITUAN)  or  at  external  storage  devices. 

type  STORE  (type  INDEX,  type  CONTENTS)  declares  inappmg,access  .alter  ,newindex  : 

based  on:  INDEX, CONTENTS 
sorts:  mapping 

opns:  initialize  :  — »  mapping 

access  ;  mapping  x  index  — »  content 

alter  :  mapping  x  index  x  content  — »  mapping 

newindex  :  mapping  — »  index 

axioms:  V  mapping  m,  index  i,  j,  content  x  : 

access(alter(m,i,x),i)  -x 

access  (alter  (m,  i,x),j) access(m,j)  if  i  j 

V  mapping  m  :  3  index  i : 
newindex  (m)  =  i 

required:  V  mapping  m,  index  i  ; 

m  ^  initialize  for  access  (m,i) 
i  y*  newindex (m)  for  access(m,i) 

end  of  type 

Note  that  the  operation  newindex  is  incompletely  specified  (it  should  bo  viewed  as  an  enrichment); 
all  we  require  is  that  it  is  a  totally  defined  operation  and  that  the  index  differs  from  all  those 
occurring  in  the  given  object  m.  Furthermore,  the  type  STORE  is  parameterized  since  we  may  use 
it  for  variou.s  kinds  of  indices  and  contents. 

It  is  clear  that  this  type  corresponds  to  classical  notions  in  programming  languages  such  .as  ALGOL 
or  I’ASCAf/.  Without  going  into  details  we  will  briefly  sketch  here  what  the  correspon:lenccs  look 
like  in  the  style  of,  say,  PASCAL  (cf.  [10]). 

(a)  If  the  type  mapping  is  to  be  interpreted  a.s  a  file  we  get  the:  following  correspondences  (where 
the  notation  of  [10]  is  extended  to  the  case  of  direct  access  files): 

The  type  declaration  reads:  type  mapping  -  file  of  content; 

Further  correspondences  are:  access  (f,i)  <=»  got(f,  i) 

f  alter{f,  i, x)  <=»  put(f,  i, x) 
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(b)  ir  Iho  interpretation  is  made  in  terms  of  pointers,  the  correspondence  looks  slightly  confusing 
since  the  object  mapping  m  becomes  anonymous  (i.c.  is  not  listed  explicitly). 

There  is  no  type  delaration  for  mapping. 

Declaration  of  index:  type  index  t content; 

Further  correspondences:  var  i  :  index  ==  newindex(nn)  <=»  var  i  :  Tcontent; 

access(m,i)  <=>  it 

m  :=  alter <=»  it  :=  x 

(c)  Finally,  there  is  an  interpretation  in  terms  of  (unbounded)  arrays: 

Declaration  of  mapping:  type  mapping  =  array  of  content; 

Further  cori  ospondenccs:  access  (a,  i)  <=»  a[i] 

a  :=  alter(a,  i,  x)  <=>  aji]  :=  x 

Because  of  its  notational  beauty  we  will  stick  to  this  last  interpretation  for  the  rest  of  this  paper. 

The  type  STORE  can  be  used  to  specify  an  implementation  of  trees.  Since  the  description  of  the 
formal  treatment  is  (juite  lengthy  we  have  moved  it  to  the  appendix.  Here  we  will  only  give  the 
basic  idea:  In  pointer  implementations  the  objects  themselves  arc  replaced  by  references  to  them. 
(In  A1XIOL68  this  is  the  only  way  of  writing  down  something  like  a  recursive  type  declaration.) 
This  leads  to  the  two  type  declarations  (where  index  stands  for  the  references). 

type  tree' s  leaf  (elem  item )  |  cons  (index  sonl ,  index  son2 ) 
type  tree  ^  (mapping  A,  index  r) 

where  mapping  is  dclincd  by  the  instantiation  STORE(index, tree')  of  the  above  type  scheme. 

As  is  well-known,  an  implementation  of  c.g.  cons(a,b)  means  to  build  the  disjoint  union  of  two 
mappings  and  analogously  sonl  (a)  means  to  extract  a  submapping.  But  we  are  not  inU'rested  in 
this  full  generality.  We  rather  seek  a  transformation  that  implements  a  class  of  itnportant  special 
cases  ediciently.  Consider  the  example 
t'  "  t[s  <=  u] 

with  s -=  cons(cons(a,  b) ,  c)  and  u  ^  cons(  cons(a,  leaf(x)) ,  cons(b,  c) )  . 

Here  the  new  tree  u  is  built  up  from  subtrees  of  the  orignal  tree  s  and  primitives  such  as  leaf(x). 
(/on.seqiK'ntly  the  mapping  representing  the  new  overall  tree  t'  will  ordy  slightly  dilTer  from  the 
one  representing  t.  i.et  m  be  the  mapping  representing  the  old  tree  t  in  the  example  above  and  let 
m'  be  the  new  mapping  representing  t'.  Then  m'  is  given  by  the  expression  (where  the  auxiliary 
identifiers  shall  not  only  incrca.se  readability  but  also  inilicate  in  which  order  the  computations 
will  take  place  in  a  procedural  implementation).  Note  that  all  the  identifiers  s,  a,  etc.  row  stand 
for  indices. 

ni  “  newindex(m) 

mj  -  alter (m,  n I ,  cons(b,  c)) 

n-j  "=  newindex(mi) 

m2  ’  alter  (m  1 , 02,  leaf  (x)) 

m;)  =  alter(m2,  sonl  (m(s)),  cons  (a,  02)) 

m'  =  alter(m3,  r,  cons(sonl  (m(s)),  ni)) 

'I'he  appendix  shows  that  the  transition  from  the  expression  substitute(. . . )  to  an  expression 
alter(...)  indeed  can  be  done  in  a  fully  mechanical  and  formal  w;iy.  ’I'he  r<'sulting  tr-atisforma- 
lion  .simply  captures  a  standard,  yet  burdensome  and  error-prone,  implementation  technicpie  in  a 
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schematic  Form  which  then  can  be  safely  applied.  And  the  above  example  is  a  convincing  argument 
for  the  desirability  of  such  a  mechanical  transition. 


TVansformation:  The  transformation  POINTER-IMPLEMENTATION(TREEl)  yields  a  new  type 
where  the  special  operations  such  as  add  of  the  type  TREEl  are  specified  in  terms  of  alter(. ..), 
provided  they  meet  the  requirements  sketched  above. 

The  mechanical  nature  of  this  transformation  will  be  demonstrated  in  the  appendix. 


3.6.  Pointer  Implementations  of  Traversable  Trees 

It  is  trivial  to  combine  the  last  two  transformations.  In  the  case  of  a  traversable  tree  we  get  the 
declaration  (tree'  remaining  the  same) 

type  tree  ^  (mapping  A,  index  r,  index  c) 

The  operations  reset,  up  and  down  only  change  the  index  c  but  leave  the  mapping  invariant.  The 
operation  subst  alters  the  mapping  but  leaves  the  index  c  untouched. 

Transformations:  TRAVERSABLE-POINTER-IMPLEMENTATION(TREE, TREEl, P)  generates  a 
type  that  provides  operations  such  as  up,  down.  Add  etc.  and  specifies  them  in  terms  of  the 
operations  access,  alter  etc.  of  the  type  STORE. 

The  mechanization  of  this  transformation  is  trivial  once  one  knows  how  to  do  the  transforma¬ 
tion  POINTER-IMPLEMENTATION.  This  means  that  our  automatic  program  development  has 
proceeded  considerably  further:  Again  assuming  that  the  type  EXTENDED  TREE  implements  the 
type  DICTIONARY  we  have  now  arrived  at  a  pointer  implementation  of  the  type  DICITONARY. 
And  still  the  user  only  had  to  provide  the  tree  declaration  and  the  operations  add,  delete,  etc. 


3.7.  Tree  Traversal  for  Several  Processes 


As  soon  as  we  work  in  a  concurrent  environment  there  arises  the  need  for  several  “current 
subtrees”,  which  is,  of  course,  a  straightforward  generalization  of  the  type  TRAVERSABLE  TREE. 
Conceptually  this  leads  to  an  (n  +  l)-tuple  of  trees,  where  n  trees  are  subtrees  of  the  n  +  1st  one. 
The  only  complication  will  be  that  we  have  to  keep  the  subtree  relations  between  various  current 
trees  intact.  The  auxiliary  type  name  denotes  a  set  of  names  for  the  proce.sses  working  on  the 
tree  (without  loss  of  generality  we  may  again  take  the  integral  numbers  here).  The  predicates 
are  as  in  section  3.3,  the  meaning  of  the  underlining  will  be  explained  in  the  next  section. 

type  MULTIPLE  TREE  declares  mtree,reset , down  ,up  .current  : 


based 

on:  PTREE 

sorts: 

mtree 

opns: 

init  : 

tree 

mtree 

reset  : 

name  x  mtree 

-» 

mtree 

down  : 

name  x  mtree 

— ► 

mtree 

HIE  = 

name  x  mtree 

mtree 

root  : 

mtree 

—¥ 

tree 

current  : 

name  x  mtree 

-» 

tree 

axioms:  V  trees,  mtree  tt,  name  ?c,  ft: 

root(init(s))  -  s 

root  (reset  ^(tt))  =■  root(tt) 

root(dgwn.jj(tt))  =  root(tt) 
current,,  (reset  ^,(tt))  =  root(tt) 
current  ^(  reset  ,,(tt))  =  current«(t) 
current,i(dov^jj(tt))  =  son  j(curr6nt^(tt)) 
current, (down  ji(tt))  =  current  ,r(tt)) 
u£^(down-^(tt))  -  tt 

up„(down,,(tt))  =  dowrL^(up^{tt)) 
required:  V  mtree  tt,  name  tt,  tree  s  : 
current,r(tt)  root{tt) 

P„(current„(tt))  =  true 

current,„(tt)  root(tt)  for  up^(tt) 
-'(current,,r(tt)  is  leaf )  for  down  ,r(tt) 

end  of  type 


if  X  r*  /i 

if  P,^(son,  (current  ,x(tt)))  =  true 
if  It  ^  fi 

if  IT  ^  (1 


The  same  extension  as  for  simple  traversable  trees  adds  an  operation  “substitute”  that  replaces 
one  of  tlu!  current  subtrees.  However,  the  requirement  that  all  other  current  trees  remain  subtrees 
adds  some  further  restrictions. 

type  MULTIPLE  TRBE+  declares  subst  : 

enrich  MULTIPLE  TREE  ffi  TREE"*"  by 
opns:  subst  :  name  x  mtree  x  tree  —*■  mtree 

axioms:  V  mtree  tt,  tree  s,  name  fi,  it : 

root(subst,i(tt,  s))  =  root(tt)[current,i(tt)  t=  s] 

current  j,(subst^(tt,  s))  =  s 

current,r(subst,i(tt,  s))  =  current,r(tt)[current,i(tt)  s]  if  fi  it 
required:  V  mtree  tt,  tree  s,  name  /t,  x  : 

P,i(s)  =  true  for  subst^(tt,  s) 

current„{tt)  -<  current^(tt)  =»  current,r(tt)  s  for  subst,i(tt,  s) 
end  of  type 

The  third  eriuatiun  and  the  restriction  .arc  both  enforced  by  the  requirement  that  invariantly 
current,r(tt)  ^  root(tt).  Note  th.at  the  restriction  .allows  the  substitution  of  a  subtree  that  is 
current  for  two  processes.  (The  symbol  means  “is  subtree  but  not  equal”.) 

As  in  section  .‘i.'l  we  now  get  operations  add^  and  Add,^: 


type  MULTIPLE  TREEl  declares  add  : 

enrich  MULTIPLE  TREE  by 
opns:  add  :  name  x  mtree  x  elcm 
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mtree 


axioms:  V  mtree  tt,  elem  y,  name  fi  : 

add^(tt,y)  -  tt  if  item (current^(tt))  -  y 

=  subst^(tt,  cons  (current^(tt),  leaf  (y)) )  otherwise 

required:  V  mtree  tt,  elem  y,  name  fi  : 

current  jj(tt)  is  leaf  for  add^(tt,y) 

end  of  type 

type  EXTENDED  MULTIPLE  TREE  declares  Add: 
enrich  MULTIPLE  TREE  1  by 

opns:  Add  :  name  x  mtree  x  elem  — ►  mtree 

axioms:  V  mtree  tt,  elem  y,  name  /x  : 

Add^(tt,y)  =  Add (down ^(tt),y)  if  ->(  current^(tt)  is  leaf  ) 

Add^(tt,y)  =  add^(tt,y)  if  current^(tt)  is  leaf 

end  of  type 


'I'lio  pointer  itnpleinentation,  too,  is  a  straightforward  extension  of  tiic  principles  used  in  section 
3.5  and  3.6.  Now  we  get 

type  tree  -  (mapping  A,  index  r,  index  C| ,...,  c„) 

where  the  operations  reset^,  up^  and  down^  only  change  the  index  c^  while  subst^  alters  the 
mapping  A. 

'file  type  MULTIPLE  TREE  (respectively  its  implementation)  specifies  the  overall  behavior  of  the 
concurrent  processes  including  their  shared  and  private  variables.  In  this  .sense  the  axioms  and 
re(|uir('metits  correspond  to  the  ‘'always”-operator  □  of  temporal  logic.  In  the  next  section  we 
h.ave  to  discuss  the  relationship  between  this  type  and  concurrent  programs.  In  particular,  it  must 
be  decided  how  the  interle.aving  of  seciuences  of  operations  takes  place,  for  so  far  every  process 
completes  its  opc-ralion,  say  Add^,  before  another  one  starts  a  new  operation,  say  Delete,^- 


3.8.  Concurrency  and  Protection 

VVe  deal  here  with  a  particular  class  of  concurrency  problems:  Synchronization  is  only  needed  to 
keep  processes  from  interfering  with  each  other  while  accessing  a  common  variable.  'I'herefore 
it  is  justilied  that  we  base  our  a()proach  on  the  so-called  rnultiprogramming-a.ssurnption,  where 
p.irallelism  is  modelled  by  se<|uential  interleaving.  The  essential  point  here  is  that  the  operations 
are  .-issumc'd  (o  be  ntaniic.  Whenever  an  implementation  be  it  hardware  or  software  realizes 
such  a  “concept  u.ally  atomic”  operation  by  a  sequence  of  [nore  elementary  operations,  there  must 
be  a  itiechanism  that  treats  this  se(|uence  as  an  indivisible  unit.  In  the  literature  various  such 
tnechanisitis  are  known  (sem.iphores,  locks,  conditional  critical  regions,  etc.)  We  will  use  here  the 
one  that  has  been  tailored  lo  the  ii.se  in  large  struclered  objects,  viz.  locks.  In  their  simplest 
lorm,  locks  act  like  sema|)hores  that  are  a.ssociate«l  to  the  shared  variables  of  proces.ses.  Let  v  be 
such  a  vari.able.  Then  lock(v)  blocks  that  vari.able  (no  two  proce.sses  m.ay  hold  locks  on  a  variable 
simultaneously)  ,itid  unlock  (v)  frei-s  it.  'I'his  mechanism  gains  considi'r.able  expre.ssivt'  power  by 
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introducing  dilTcrcnt  kinds  of  locks,  for  example  read-  and  write-locks.  The  compatibility  relation 
between  these  locks  is  usually  specified  by  graphs  such  as 


Cco-'-ra 

where  a  solid  arc  states  that  two  different  processes  may  hold  the  respective  locks  on  the  variable 
simultaneously,  and  a  dotted  arc  means  that  a  process  may  convert  its  lock  from  one  kind  to 
the  other.  Such  behaviors  are  easily  described  by  abstract  data  types.  Hut  there  are  additional 
probhuns  that  arc  more  intrinsic  an<l  quite  lengthy;  therefore  we  have  moved  this  discussion  to  the 
appendix  and  treat  the  subject  here  in  a  more  traditional  way. 

The  goal  of  our  development  is  best  described  by  an  example  indicating  the  initial  and  the  final 
state  of  our  intended  developnrcnt.  (The  names  /i  may  be  omitted  in  these  protocols  since  they 
are  impliciiiy  given  by  the  respective  processes.) 

Example  1:  We  arc  given  processes  that  issue  operations  of  the  typo  DICTIONARY. 

|[  ...  II  w-lock(s);  s  :=  insert(s,  x);  w-unlock(s)  ...  ||  ...  J 

In  the  final  program  this  shall  become  (where  according  to  the  pointer  implenjcntatiot)  of  .section 
3.6  the  index  c  denotes  the  current  subtree  of  the  process  under  consideration  and  an  array  notation 
is  used) 

If  ...  II  ::  ...  r-lock(s(c]); 

until  s[c|  U  leaf 

do  c'  ~  c;  c  --  down(s(c)):  r-unlock  (s(c'l);  r-lock  (sfej)  od; 
w-lock (s[c]);  s[c)  :=  add{s[c],x);  w-unlock (s[c)) 

...  II  ...  I 

(h'nd  of  example) 

1’he  purpose  of  the  transformation  to  be  found  is  therefore  twofold:  When  the  recursive  func¬ 
tion  insert  is  implemented  by  a  loop,  the  locking  shall  not  continue  throughout  the  iteration. 
!''urthermore,  not  the  whole  object  but  only  the  currently  accessed  part  i;;  to  be  locked.  In  the 
se<|uel  we  will  deal  with  both  problems  in  turn. 

Ilecall  I  he  ecpii  valence  relation  of  section  3.1,  where  two  trees  arc  equivalent  if  they  have  the  same 
si't  of  leaves.  Under  this  e<iui valence  relation  the  operations  reset,  up  and  down  are  the  identity 
and  therefore  can  be  taken  out  of  the  critical  region.  Wo  delay  the  details  to  the  appendix  and 
assuiiK'  for  the  time  being  that  certain  operations  -  marked  here  by  underlining  allow  the 
following  (informal)  transformations 

(Tl)  lock(t);  t  down (t) 

- () - 

r-lock(t);  t  •=  down_(t);  r-unlock(t);  lock(t) 

I'his  means  that  a  down-operation  that  immcdi:xtely  follows  a  locking  allows  .in  inti-rruption  of  the 
locking  afl.iT  its  execution.  The  analogous  rule  holds  for  an  unlocking  after  the  down-operation. 
Hut  nf)te  that  such  an  interruption  is  not  permitted  in  the  middle  of  a  critical  region.  In  .addition 
we  need  technical  rules  such  as  distribuUvity  over  conditionals  that  have  to  be  extimded  from 
cl,i.s.sical  programming  constructs  to  locks: 
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(T2)  lock(t);  if  p(t)  then  A  else  B  fi 

- - 

r-lock(t);  if  p(t)  then  lock  (t);  A  else  lock(t);  B  fi 
In  both  transformations  lock  stands  for  either  read-locks  or  write-locks. 

These  rules  together  with  the  meanwhile  classical  fold/unfold  techniques  of  Burstall  and  Darlington 
sullice  to  restrict  the  locking  to  the  actually  necessary  periods  of  time:  We  start  from  the  sequence 
of  operations  that  stems  from  implementing  insert  by  Add 

w-lock(t);  t  :=  Add(t,  x);  w-unlock(t) 

and  make  it  into  a  the  procedure 

proc  Add*  «  (mtree  t,  elem  x)mtree  :  w-lock(t);  t  ;=  Add(t,  x);  w-unlock(t) 

Unfolding  of  the  recursive  definition  of  Add  given  in  the  type  EXTENDED  TRAVERSABLE  TREE 
yields  after  a  few  minor  simplifications 

proc  Add*  (mtree  t,  elem  x)mtree  : 
w-lock  (t); 

if  -'(t  is  leaf)  then  t  ;=  down  (t);  t  :=  Add(t,  x);  w-unlock  (t) 

else  t  add  (t,x);  w-unlock (t)  fi 

Application  of  the  above  transformations  and  some  simplification.s  yield  the  version 

proc  Add*  -  (mtree  t,  elem  x)mtree  : 
r-lock  (t); 

if-'(tis  leaf)  then  t  ■=  down  (t);  r-unlock(t);  w-lock(t);  t:=  Add(t,x);  w-unlock(t) 

else  w-lock (t);  t  :=  add (t,x);  w-unlock  (t)  fi 

Now  we  have  an  Instance  of  the  original  definition  of  Add*,  which  allows  folding  and  thus  produces 
a  version  that  directly  corresponds  to  a  loop: 

proc  Add*  (mtree  t,  elem  x)mtree  : 
r-lock  (t); 

if -i(tis  leaf)  then  t  =  down  (t):  r-unlock(t);  Add*(t,  x) 

else  w-lock (t);  t  :=  add(t, x);  w-unlock (t)  fi 

'Phe  second  problem  to  be  addressed  here  is  that  of  locking  only  the  actually  accessed  nodes 
instead  of  the  whole  tree.  After  the  application  of  the  transformation  of  sections  3.5,  3.6  we  h<avc 
a  collection  of  individual  objects  in  the  place  of  the  monolithic  single  tree.  (We  will  use  the  array 
notation  here.)  'Phe  following  transformation  describes  the  transition  from  the  locking  of  the  whole 
array  to  the  locking  of  .single  entries: 

(T.3)  lock  (a);  a[i]  ==  e;  unlock  (a) 

- - 

lock(a(ij);  a[i]  ~  e;  unlock (a(ij) 
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If  several  elements  are  accessed  in  the  criUcal  region  they  have  to  be  locked  simultaneously.  (As  is 
well  known  such  a  simultaneous  locking  can  be  implemented  sequentially  by  establishing  an  order 
relation  between  the  single  elements.  In  our  case  “father  before  son”  would  be  an  obvious  choice.) 
This  simultaneous  locking  even  can  distinguish  read-  and  write-locks.  Of  course,  an  application  of 
this  transformation  is  only  reasonable  if  the  number  of  elements  accessed  in  the  critical  region  is 
limited. 

There  remains  one  issue.  The  abstract  data  type  MULTIPLE  TREE  requires  that  a  substitution 
must  not  take  place  if  certain  subtrees  are  the  current  trees  of  other  processes.  In  a  sequential 
environment  violation  of  such  a  requirement  causes  the  program  execution  to  abort.  In  a  concurrent 
environment  we  would  rather  see  the  process  wait  until  some  other  process  has  resolved  the 
violation.  (If  no  other  process  is  kind  enough  to  do  this  we  have  infinite  waiting^.)  The  simple 
solution  is  a  re-interpretation  of  the  undefinedness  expressed  in  the  restrictions  of  our  data  types. 
VVe  will  adopt  this  solution  here  for  the  sake  of  brevity  although  it  has  severe  drawbacks  from  a 
practical  point  of  view:  A  process  repeatedly  locks  and  unlocks  the  variable  in  question  just  to  see 
whether  the  violation  still  exists.  In  this  way,  it  continuously  interferes  witli  the  other  processes. 
Furthermore,  testing  of  the  violation  means  that  it  has  to  know  what  the  current  subtrees  of  the 
other  processes  are.  Both  problems  are  typical  candidates  for  a  solution  by  locks.  Therefore  we 
might  introduce  two  new  kinds  of  locks,  one  standing  for  “1  am  here”  and  the  other  standing  for 
“I  am  the  only  one  here”.  The  former  is  compatible  with  both  read-  and  write-locks,  the  latter 
with  no  lock.  Although  this  leads  to  the  most  practical  solution  we  will  not  pursue  the  subject 
here  further. 


3.9.  Summing  up  the  Transformations 

What  have  we  gained  by  the  lengthy  considerations  of  this  chapter? 

Assume  that  the  aforementioned  tools  and  transformations  indeed  are  at  our  dispos.al  (maybe  even 
aided  by  a  mechanic.al  systian).  If  we  now  have  to  develop  a  program  that  .applies  some  fairly 
complex  operations  to  a  certain  tree  structure  i.e.  to  a  recursive  data  .^tin-ture  then  all  we 
have  to  do  is  specify  the  individual  tree  transformations  (for  exaiTiple,  how  a  new  le.af  may  be  added, 
how  restriicterings  can  be  done  etc.)  Since  this  specification  is  not  burdened  by  itnplementation 
details,  it  very  clearly  reveals  t'.e  underlying  algorithmic  ideas. 

Once  this  step  is  done,  the  rest  of  the  itnplementation  can  be  done  almost  automatically  by  applying 
our  transformation  rules.  The  result  is  a  program  that  does  the  desired  operations  in  a  pointer 
imphnnentation  and  possibly  even  in  a  concurrent  environment. 

'fhe  rest  of  this  paper  will  present  an  application,  viz.  the  development  of  concurrent  operations 
on  2-3-trecs.  According  to  the  .iforementioned  principles  it  will  suffice  to  describe  the  various 
individual  operations  as  basic  tree  operations. 


■•(^otnprirr  the  ongoing  <lis|>ulc  in  the  .irea  of  prograniniing  l.angii.agc  soiniinlirs  wlicUicr  it  is  adniissihin  to  identify 
abortion  and  nontnrmi  nation. 
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4.  An  Application:  Implementing  Sets  by  2-3-Trees 


I  low  do  the  aforementioned  techniques  apply  in  a  concrete  program  development?  First  of  all, 
recall  that  it  suflices  to  cast  one’s  ideas  about  the  algorithm  into  basic  tree  transformations.  The 
rest  of  the  development  is  done  using  the  rules  of  the  previous  chapter.  Therefore  we  will  develop 
here  a  se()uence  of  more  and  more  refined  versions  of  trees  together  with  suitable  enrichments  until 
all  our  intentions  arc  met.  'rhese  intentions  are  essentially  those  given  in  the  literature  on  2-3-trccs 
and  H-trees  and  they  will  be  explained  in  due  course.  This  leads  to  a  nicely  structured  development 
process  where  we  cope  with  one  issue  at  a  time. 


4.1.  Basic  2-3-Trees 

The  average  performance  of  the  tree  operations  is  best  when  the  trees  arc  “balanced’,  i.e.  when 
all  paths  have  the  .same  length.  Obviously  addition  as  well  as  deletion  violate  this  property  unless 
a  restructcring  of  the  tree  takes  place.  The  costs  of  these  restructerings  can  be  kept  low  —  in  the 
order  log  N  if  2-3-trecs  (or  more  generally  B-trccs)  arc  used.  In  a  2-3-tree  every  node  (except 
for  the  leaves)  has  cither  two  or  three  sons.  The  type  2-3-TREE  is  therefore  defined  by 

type  tree  =  leaf(elem  item)  | 

cons2(tree  sonl,tree  son2)  | 
cons3(tree  son  1 ,  tree  son2  ,tree  son3) 

(We  will  often  use  the  notation  .  is  cons  as  an  abbreviation  for  .  iscons2  V  .  iscons3.)  In  data 
base  applications  one  usually  works  with  the  more  general  H-trees  (cf.  [1]),  where  every  node  has 
between  m  and  2m  -  I  .sons.  Clearly  2-3-trccs  arc  just  the  special  case  m  =■  2.  For  .simplifying  the 
presentation  we  will  restrict  ourselves  to  this  special  case. 


4.2.  Ordered  Trees 

A  first  derision  that  consiilcrably  increases  the  efficiency  of  the  intended  implementation  is  to 
use  oidy  “ordered  trce.s’’.  The  straightforward  specification  of  this  requirement  would  be  to  use 
functions  min  arxl  max  that  yield  the  smallest  and  largest  leaf  of  the  tree.  But  the  values  of  these 
functions  m.ay  change  on  deletion  or  addition.  Therefore  it  is  better  to  work  with  upper  and  lower 
bounds.  This  leads  to  the  following  redefinition  of  the  basic  2-3-trce8  into 


type  tree  ^  leaf  (elem  low,  elem  item  ,  elem  high)  | 
cons  2(tree  son  1 ,  tree  son2)  | 
cons3(tree  son  1,  tree  son2,tree  son3) 


Using  these  hounds  the  ordering  requirement  is  easily  specified.  (By  +1  we  denote  the  successor  of 
an  element  of  the  type  elem,  which  is  from  now  on  .assumerl  to  be  linearly  ordered.) 
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type  ORDERED  2-3-TREE  declares  Iwb.upb  : 


enrich 

2-3-TREE  by 

opns: 

upb  :  tree  —*  elem 
Iwb  :  tree  -♦  elem 

axioms: 

V  tree  t : 

Iwb(t)  low(t) 

if 

t  is  leaf 

=  Iwb  (son  1  (t)) 

if 

t  is  cons 

upb(t)  =  high(t) 

if 

t  is  leaf 

=  upb(son2(t)) 

if 

tis  cons  2 

=  upb(son3(t)] 

if 

tis  cons 3 

required: 

V  tree  t : 

upb(sonl(t))  +  1  =  lwb(son2(t)) 

upb(son2(t))  +  1  lwb(son3(t))  if  tisconsS 

end  of  type 


Note  that  this  is  a  specification  and  docs  not  prescribe  any  particular  implonicntation.  The  optimal 
solution,  where  the  information  about  the  bounds  is  distributed  all  over  the  tree  (cf.  [1]),  is  still 
included  here. 

The  ordering  also  provides  us  with  a  predicate  P  as  required  in  section  3.1®:  For  an  arbitrary  value 
y  -  actually  the  one  to  be  .searched  in  the  tree  —  the  predicate  Py(t)  is  Iwb(t)  <y  <  upb(t).  Due 
to  the  definitions  of  Iwb  and  upb  this  is  true  for  exactly  one  of  the  sons  if  it  is  true  for  tlic  father. 
Thus  we  introduce  the  type 


type  PTREE  declares  P  ; 

enrich 

ORDERED  2-3-TREE  by 

opns: 

P  :  tree  —*■  bool 

axioms: 

V  tree  t,  elem  y  : 

Py(t)  =  true  if  Iwb(t)  <  y  <  upb(t) 

false  otherwise 

required: 

V  tree  t : 

rP(sonl(t))  V  P(son2(t))l  -  true  if 

(P(sonl(t))  A  P(son2(t)))  -  false  if 

ti*  cons  A  P(t)  =  true 
tis  cons  A  P(t)  “  true 


end  of  type 


The  requirements  arc  fulfilled  by  definition. 


“As  a  inallor  of  fact,  lliis  roqiiircmcnl  motivates  the  introduction  of  an  ordering. 
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4.2.  Addition  and  Deletion  of  Leaves 


The  basic  operations  needed  for  implementing  sets  in  terms  of  trees  are  addition  and  deletion  of 
leaves.  This  can  be  done  according  to  the  following  figures. 


Example  2:  Consider  the  addition  of  the  value  2  to  the  trees  given  below;  this  leads  to  the 
following  tree  transforniations 


Case  1:  addition  of  the  value  2 


r 


Case  2:  addition  of  the  value  2 


{End  of  example) 


Example  3:  Assume  that  we  want  to  delete  the  value  2  from  the  tree  given  below. 


Case  3:  removal  of  the  value  2 


The  problem  with  this  solution  is  that  the  node  r  disappears  when  it  has  only  two  sons  one  of 
which  is  to  be  deleted.  This  is  unpleasant  when  it  comes  to  concurrency,  since  such  problems 
are  c.Tndidatcs  for  deadlock  situations.  To  shorten  the  presentation  we  adopt  another  solution 
and  introduce  the  notion  of  an  empty  tree  (a  leaf  without  an  item).  This  means  that  we  add  the 
variant  empty  (elem  low,  elem  high)  to  the  recursive  type  declaration  above  and  extend  the  type 
ORDERED  2-.S-TREE  accordingly.  Ily  sis  terminal  we  abbreviate  (sis  leaf  v  sis  empty).  Thus  we 
get  the  transformation  (where  no  nodes  need  to  be  eliminated  for  the  time  being). 

r 

/\ 

1  O 

Case  4:  deletion  of  the  value  2 


{End  of  example) 
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The  spccificntion  of  these  operations  according  to  the  above  figures  is  easy.  To  shorten  tlio  writing- 
down  we  neglect  the  optimal  solutions  of  cases  1  and  3  and  treat  all  situations  according  to  cases 
2  and  4. 

type  TREEl  declares  add, delete  : 
enrich  PTREE  by 

opns;  add  :  tree  x  elem  — ►  tree 

delete  :  tree  x  elem  -+  tree 
axioms:  Velem  x,y,  I,  h  : 


add  (leaf  (1,  x,  h),y)  =  cons2(leaf(l,  x,  x),  leaf  (x  i-  1 ,  y,  h)) 

if 

X  <  y 

=  leaf(l,  X,  h) 

if 

X  =  y 

=  cons 2(leaf(l,y,y),  leaf  (y  i  l,x,h)) 

if 

X  >  y 

add(empty(f,  h),y)  =»  leaf(l,y,h) 

delete(leaf  (1,  x,  h),y)  =■  leaf(l,x,  h) 

if 

X  ip.4  y 

=  empty  (I,  h) 

if 

X  =  y 

delete  (empty  (I,  h),y)  -=  empty  (l,h) 
required:  V trees,  elemy: 

s  is  terminal  A  Iwb (s)  <  y  <  upb(s)  for  add(s,y) 

s  is  terminal  A  Iwb (s)  <  y  <  upb(s)  for  delete(s,y) 

end  of  type 

The  transformations  of  .section  3.2  now  produce  a  type  EXTENDED  TREE  or  a  type  EXTENDED 
TRAVERS ABl.E  TREE,  which  are  both  implementations  of  the  type  DICTIONARY.  Note  that  as  a 
byproduct  of  the  ordering  the  subtree  where  the  addition  and  deletion  take;  place?  is  uniipiely  deter¬ 
mined,  Ihus  making  the  potential  nondeterminism  in  the  transformation  of  section  3.2  harmless. 
Also,  the  extension  to  multiple  trees  is  easy  .since  no  substitution  erases  a  subtree. 


5.  Repairing  Degenerate  Trees 

The  operators  defined  above  produce  trees  that  may  be  degenerate  in  either  of  twt)  w.ays:  There 
may  be  empty  subtrees  as  the  result  of  a  deletion;  these  subtrees  should  be  erased.  And  there  may 
be  search  paths  through  the  tree  that  are  considerably  longer  than  other  paths;  but  for  a  better 
overall  performance  of  the  tree  operations  all  paths  should  have  (he  same  lengt  h.  The  purpose  of 
working  with  2-3-trecs  inste;ul  of  ordinary  binary  trees  is  to  allow  the  re-balancing  of  degenerate 
trees  without  too  much  overhead. 

Tlir  prirnupal  idea  of  the  repairing  can  by  abusing  a  terminology  of  artilici.al  intelligence  be 
skc'tched  as  follows:  'I’he  operations  add  and  delete  search  (he  leaf  in  (picsiion  .and  then  .apply  the 
necc.ssary  changes.  'Pfiese  changes  may  cause  a  disturbance  of  the  balancing.  Whenever  such  a 
degeneration  exists  “a  demon  is  triggered”  that  tries  to  repair  the  tree'.  Thi'  actions  of  Ibis  demon 
may  lead  to  further  disturbances  which  are  treated  in  turn  until  the  tree  is  in  perfect  shape  again. 
This  principle  leaves  a  number  of  choices:  The  “demon"  may  be  one  or  more  proc.'sses  t  hat  are  part 
of  the  data  strucuture  itself  such  that  the  requesting  proce.sses  are  not  ('ven  aware  of  something 
going  on  in  the  data  b.ase  after  they  have  finished  their  task.  Mut  one  also  m;iy  chargi'  tin'  process 
ri'spon.sible  for  the  degener.ation  with  the  ta.sk  of  the  demon  by  forcing  it  to  do  .all  necessary  repairs 
before  leaving  the  data  base.  In  both  cases  there  is  a  further  decision  possible,  vi/.  tin'  decision 
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whether  the  treatment  of  one  degeneration  may  produce  at  most  one  or  several  new  disturbances. 
These  issues  will  be  treated  in  detail  later  on. 


5.1.  Balanced  Trees 

To  express  the  balancing  requirement  wo  need  an  operation  that  determines  the  “height”  of  a  tree, 
i.e.  its  distance  from  the  leaves.  However,  in  the  case  of  unbalanced  trees  such  an  operation  is  not 
well-defined.  To  overcome  this  deficiency  we  associate  to  each  (sub)trce  a  “disturbance”  that  is 
>-l- 1  if  the  tree  is  too  high  in  comparison  with  its  environment  and  <-l  if  it  is  too  short;  otherwise 
the  disturbance  is  0.  Then  we  can  replace  our  previous  notion  of  height  by  a  “virtual  height", 
which  is  corrected  by  the  disturbances.  This  calls  for  another  modification  of  the  original  type 
2-3-TREE: 

type  tree  =  empty  (int  dist,elem  low,elem  high)  | 

leaf  (int  dist ,  elem  low,  elem  item ,  elem  high)  | 
cons 2(intdist, tree  sonl  ,tree  son2)  j 
cons3(int  dist,  tree  sonl  ,tree  son2,tree  son3) 


The  balancing  reiiuircment  now  can  be  formulated  by  the  type 

type  BALANCED  2-3-TREE  declares  height  : 

enrich  2-3-TREE  by 

opns:  height  :  tree  -♦  int 

axioms:  V  tree  t : 

height(t)  = -dist(t)  if  t  is  terminal 

=  height{sonl  (t))  -t-  1  -  dist(t)  if  t  is  cons 

required:  V  tree  t  : 

height(sonl  (t))  height(son2  (t))  if  t  is  cons 

height(son2(t))  =  height(son3  (t))  if  t  is  cons  3 

end  of  type 

The  height  gives  for  any  path  p  from  the  root  to  a  le;if  the  value  “number  of  edges  on  p”-“sum  of 
all  disturbances  along  p”.  For  easier  readibility  we  will  from  now  on  use  the  notation  cons2*(r, s) 
instead  of  cons  2(«^,  r,  s)  (analogously  for  leaf  and  cons3). 

The  change  in  the  definition  of  2-3-trees  requires  an  according  modification  of  the  operations  add 
and  delete: 

type  2-3-TREEl  declares  add, delete  : 

enrich  r>TREE  ©  BALANCED  2-3-TREE  by 

opns:  add  :  tree  x  elem  — >  tree 

delete  :  tree  x  elem  -♦  tree 
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axioms:  Velem  x,y,  I,  h,  int  a  : 


add  (leaf  “(1,  x,  h),y)  -  cons2"  * '  (leaf”(l,  x,  x),  leaf°(x  +  1  ,y,  h)) 

if 

X  <  y 

=  leaf  “(I,  x,  h) 

if 

X  =  y 

=  cons 2“  '  '(leaf®(l,y,y),  lcaf“(y  +  1,  x,  h)) 

if 

X  >  y 

add(empty“(l,  h),y)  =  leaf "(l,y,  h) 

delete(leaf“(l,  X,  h),y)  =  leaf“(l,x,h) 

if 

X  y 

=  empty  "(l,  h) 

if 

X  =  y 

delete(empty  “(I,  h),y)  =  empty“(l,h) 
required:  V trees,  elem y  : 

s  is  terminal  A  Iwb(s)  <  y  <  upb(s)  for  add(s,y) 

s  is  terminal  A  Iwb (s)  <  y  <  upb(s)  for  delete(s,y) 

end  of  type 

Hy  tlic  same  construclion  as  before  this  becomes  an  implementation  of  DICTIONARY.  Note  that 
height(add(s,y))  “  height(s)  and  height(delete(s,y))  =■  height(s). 


5.2.  Local  Rebalancing 

Tlie  following  figures  shall  give  a  first  intuitive  idea  of  the  operations  that  arc  used  to  repair 
degenerate  trees.  The  notation  r(„)  indicates  the  disturbance  of  r. 

Example  4:  Lmpty  subtrees  have  to  be  eliminated.  The  only  problematic  case  arises  when  there  is 
only  one  brottuT.  'I'he  resulting  shortening  of  the  tree  has  to  be  compensated  by  the  disturbances. 
(Not<!  that  a  may  be  empty  as  well.) 

r  (p)  3  (p+rt-i) 

/\ 

a  („)  O 

Case  1:  Eliminating  empty  subtrees 


(Em/  of  example) 

For  the  rest  of  this  section  we  will  be  concerned  with  repairing  disturbed  balances,  h'or  simplicity 
we  assume  in  tin?  illustrations  below  that  the  node  b  (or  both  a  and  b)  has  a  disturbance  +1  while 
the  other  ones  have  disturbances  0. 

Example  5:  A.ssurne  that  the  node  b  in  ile,-  toiio'ving  trees ’s  unbalanced,  i.e.  has  ;i  true  height 
that  is  (by  1)  greater  than  that  of  its  brothers. 


c  d  a  c  d 

Case  2:  rebalancing  in  c:ise  of  two  sons  and  one  brother 


a 


Case  3:  rebalancing  in  ease  of  three  sons  and  one  brother 


r  r  (+1) 


Case  4:  rebalancing  in  ease  of  two  brothers 


Case  5:  rebalancing  in  ease  of  two  high  subtrees 


a'T+i)  b  (  +  1) 

/l\  /l\ 

d  e  f  g  h  i 


f  (  +  1) 


Case  6:  rebalancing  in  case  of  two  high  subtrt>.'« 


Note:  Case  5  essenliallly  also  applies  if  b  has  only  two  sons  (a  having  either  two  or  three  sons).  Of 
course,  there  also  are  various  sytnctrical  situations  where  the  roles  of  brothers  are  exchanged. 

Ilow  do  more  complex  situations  of  disturbances  inllucncc  those  pictures?  Let  us  consider  one 
repre.sentative  example  in  full  detail,  using  the  algebraic  tools  provitled  by  the  data  type  technique. 
The  intuitive  idea  reflected  in  ligurc  A  leads  to  the  general  e(|uation  (with  the  indeterminates 
a',...,  a'): 

fold  -  cons3'’(  a®  ,  cons3^(c^,  d*,  e*) ,  ) 

fnew  “  cons2^  {  cons3^*(a“  ,  c'''’,d*’) ,  cons2‘'*(e**,f^’) ) 

To  determine  the  new  disturbances  we  use  the  following  design  criteria: 

•  It  must  be  possible  to  substitute  the  now  tree  for  the  old  one  in  any  given  environment.  Therefore 
we  have  to  require  height(r„ew)  “  height(r„|j). 
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•  'I'tie  iio(l<>  which  is  Lhc  IVx  u.s  of  attention  in  our  case  b  has  to  he  coiiipletcfly  rt  paircsi.  'I'his 
means  /j'  =>  0. 

•  The  transition  should  alTect  as  few  nodes  possible.  'Phis  means  in  particular  that  we  do  not 
want  to  alter  the  disturbances  of  c,  d  and  e.  Therefore  we  recpiire  -  7,  S'  -  S,  <'  -  <  (provided 
that  this  does  not  lead  to  an  inconsistency). 

'Phe  calculations  center  around  the  axioms  and  restrictions  of  the  type  nALANCKD  2-3-TllHK.  The 
disturb.ance  a'  of  the  node  b'  is  determined  by  the  decision  fi'  =  0  and  by  the  two  restrictions 

height(cons:}^’(. . .))  =  height{cons  2"’(. . .))  A  height(e'')  ==  height(e')  -  height(d‘)  =  height(d*') 
h-  height(d*’)  h  1  -  /?'  =  height(e'  )  +  I  -  o' 
f-  o'=/3'=0. 

Analogously,  the  equations  height(d*)  =  height(d*  )  and  f)'  --  0  .allow  us  to  determine  p': 
height(r„;j)  =  height(r 

new)  ^  ^ 

|—  height(d^)  1  -  ^  +  1  -  p  =  height(d^^)  +  I  -  /3'  +  1  -  p'  =  height(d*’)  +  2  -  p' 

(—  p'  -  p  +  /3 

It  remains  to  consider  a'  and  ^ .  Using  the  last  result  p'  =■  p  +  P  this  becomes: 
height{ro;<j)  “  height( 

rncio)  ^  ^ 

|—  height(a“)  f  I  -  p  =  height(a“')  +  1  -  /3'  +  1  -  p'  =■  height(a“  )  +  2  ~  p  -  p 
(—  a'  =•  n  -  p  I-  I  and  analogously  ^  =  f  -  /3  +  1. 

When  doing  the  same  computations  for  the  other  cases  it  turns  out  that  the  last  e(]uation  (o;'  =■ 
n-P  >-  1)  always  holds  for  the  “lower”  brothers.  The  father  r  always  gets  a  new  disturbatice  of  the 
kind  p'  ^  p  +  p,  except  for  case  2  where  it  is  p'  =  p  p  -  1.  (As  a  rule  of  thumb  use  the  fact  that 
for  every  path  in  the  pictures  the  value  “sum  of  all  tlisturbances  minus  number  of  edges"  must  be 
the  same  in  bol.h  trees.) 

Mefore  we  cast  the  above  results  into  an  abstract  data  type  we  should  address  a  few  issues  hero. 

•  Assume  that  we  start  from  an  initial  tree  of  the  form  leaf*’(. . .).  'Phis  tree  h:is  lu'ight  0.  Since 
all  our  operations  are  designed  such  that  they  leave  the  height  invariant  :ind  since  this  height  is 
(for  any  path  p  from  the  root  to  a  leaf)  ecpial  to 

“number  of  edges  of  p”-“sum  of  disturbances  along  p” 
it  is  impossible  to  set  all  disturbances  to  0  'Pherefore  a  “truly  babinced”  tree  contains  at  most 
one  non/ero  disturbance,  viz.  the  one  at  the  root,  and  this  disturbance  statt's  the  length  of  all 
paths.  ('Phe  identifier  “height”  has  thus  lost  its  mnemonic  meaning  for  the  root.) 

•  Working  with  both  positive  an<l  negative  disturbances  minimizes  the  number  of  nodes  to  be 

changed.  Mut  we  could  eipially  well  use  oidy  positive  disturbances:  Consider  a  node  r  with 
disturbance  —S  <  0.  If  we  subtract  S  from  the  father  .and  add  b  to  .all  brolhers  the  dislurb.ance 
of  r  bei'ornes  0.  'Phis  doesn’t  change  anything  in  the  cases  2  6. 

•  The  sum  of  all  disturbances  of  the  tree  decre.aso.s  in  ca.ses  2  6  with  two  exceptions,  namely 

cases  .3  and  A  when  P  =  \.  In  this  case  the  sum  remains  invariant  but  the  dislurb.ance  moves 
closer  to  the  root.  'Pherefore  the  rebalancing  will  oventu.ally  terminate  (provided  that  no  further 
additions  or  deletions  take  place). 

•  I'.ach  of  the  repair  operations  keeps  the  set  of  le.aves  of  the  tree  inv.iri.anl  and  therefore  is  the 
identity  in  our  underlying  cquiv.alencc  relation. 
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5.3.  An  Abstract  Data  Type  for  Rebalancing 


According  lo  the  figures  of  the  previous  section  a  subtree  with  root  r  is  degenerated  if  at  least 
one  of  its  sons  is  empty  or  carries  a  nonzero  disturbance.  (Note  that  disturbances  of  the  root  of 
the  whole  tree  are  neglected.)  To  cope  with  the  explosion  of  case  distinctions  we  introduce  a  few 
notations  and  definitions.  In  the  figures  above  there  were  three  levels  of  nodes:  the  father  r,  the 
son  b  (or  the  sons  a  and  b)  with  the  highest  disturbance,  and  finally  the  grandsons  and  the  sons 
with  smaller  disturbances.  The  tuple  (ti,...,t„)  shall  denote  the  nodes  on  the  lowest  level  from 
left  to  right.  For  r  =■  cons3(a,b,  c)  this  can  be  formalized  as  follows  (analogously  for  cons2): 


(t„...,t„)  =  (T(a),T(b),T(c)) 
where  for  any  son  s®  of  r 

f{>. 

^(s®)  “  J  gO  — ”*onii3t  +  l 

^{sonl  (s),  son2(s),  son3  (s)), 


if  s  is  empty ; 
if  a  <  maxdist; 
if  (7  =  maxdist. 


maxdist  == 


max(dist(a),  dist(b),  dist(c))  +  1, 
max(dist(a),  dist(b),  dist(c)), 


if  dist(a)  =  dist(b) 
otherwise 


dist(c) 


Note  that  all  t^  have  the  same  height.  (The  above  formulae  are  just  the  generalization  of  the 
sample  calculation  carried  out  in  the  previous  section.)  Also,  the  strange  definition  of  maxdist 
allows  us  to  include  the  case  where  all  disturbances  arc  equal  in  a  uniform  way  (the  disturbance  is 
just  moved  to  the  father). 

The  form  of  the  transformed  tree  now  only  depends  on  the  number  n  of  elements  in  the  tuple,  c.g. 
t  =  (ti,t2,t3)  =*  r„e„,  =  cons3'’’(ti,t2,t3)  where  p' =  p  +  maxdist  -  1 


Using  these  shorthand  notations  we  can  specify  the  operation  rebalancing  by  the  following  type: 


type  2-3-TREE2  declares  rebalance  : 


enrich  PTREE  ©  BALANCED  2-3-TREE  by 
opns:  rebalance  :  tree  -♦  tree 


axioms:  V  tree  a,  b,  c,  int  a,  /3,  7  : 

let  (ti , . . . ,  t„)  and  m  =  maxdist  be  defined  as  above  in 
rebalance  (r'’)  =  empty '’“'(iwb(r),  upb(r)) 

*m— 2 

=  cons2'’+"*~'(t|,t2) 

=  cons3'’+"‘-'(t|,t2,t3) 

-  cons2'’  *‘"‘(cons2”(t| ,  tj),  cons2°(t3,  t4)) 

=  cons2'’  *^”*(cons3”(ti,t2,t3),  cons2°(ti,t5)) 

-=  cons  2'’^”*(cons3”(t| ,  to,  ts),  cons  3®(t4,  ts,  te)) 

=■  cons 3^^’"(cons3°(t| ,  t2,  ts),  cons 2”(t,|,  ts),  cons 2'’(t6,  t7)) 


required:  V  tree  t : 

dist(son,(t))  /  0  V  son i(t)  is  empty  for  rcbalance(t) 


if  n  =  0 

if  n  =  1 

if  n  "■  2 

if  n  =■  3 

if  n  "  -1 

if  n  -  5 

if  n  =■  6 

if  n  =  7 


end  of  type 
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The  peculiar  forms  of  the  first  three  cases  take  into  account  that  empty  subtrees  may  occur  side 
by  side  with  disturbances.  Note  that  the  operation  rebalance  is  the  identity  under  our  equivalence 
relation  for  trees. 

The  transformation  of  section  3.2  now  produces  the  nondeterministic  specification 


type  EXTENDED  TREE2  declares  Rebalance  : 


opns:  Rebalance  :  tree  — >  tree 

axioms:  V  tree  t,  3  tree  s  : 

Rebalance(t)  =  t[s  ^  rebalance(s)]  A  s  t  A  (dist(son,(s))  0  V  son,(s)  is  empty) 
if  3  tree  s  :  s  t  A  (dist(son4s))  0  V  son  i(s)  is  empty  ) 

=  t  otherwise 


end  of  type 


This  type  is  nondeterministic:  The  restrictions  do  not  determine  which  degeneration  is  treated  if 
there  exist  several  ones  in  the  given  tree. 


5.4.  Demons  vs.  Individual  Responsibility 

We  somehow  have  to  implement  the  nondeterministic  operation  Rebalance  of  the  previous  section. 
The  goal  can  be  described  using  the  terminology  of  a  “demon”.  When  there  is  some  degeneration 
in  the  tree  a  “demon  is  triggered”  which  miraculously  repairs  it.  If  this  repair  causes  another 
degeneration  the  demon  is  triggered  anew,  etc. 

One  solution  is  to  have  (one  or  several)  special  procc.sses  that  act  as  demons.  To  keep  them  from 
doing  exhaustive  searches  we  have  to  provide  these  processes  with  a  list  of  (potentially)  degenerated 
nodes.  Since  the  operations  add  and  delete  also  affect  this  list  it  is  a  shared  variable  (which  wo 
could  model  by  associating  it  to  the  tree). 

Another  solution  is  to  charge  the  process  causing  the  degeneration  with  its  rcjiair.  In  this  case  the 
following  property  is  particularly  pleasant;  Assume  that  we  restrict  all  disturbances  to  the  three 
values  -1,0,  +1.  Then  we  get  from  the  property  (e.g.  in  case  -1)  /3>a  the  three  possibilities  {n,P)  = 
(0, +1),  {ct,P)  =  (-1,0),  («,/?)  =  (-1,  fl).  In  the  first  and  second  case  we  get  the  new  disturbances 

=  0,  in  the  third  one  a'  =  ^ - l=f=a.  The  disturbance  of  r  becomes  cither  p'  “  p  (in 

case  2)  or  p'  =  p+  1.  The  latter  case  enforces  the  additional  restriction  p<  0  for  the  applicability  of 
the  operation  rebalance.  Analogou.sly,  in  the  cases  0,1,2  we  have  to  avoid  disturbances  <-l. 
This  may  require  that  we  shift  a  negative  disturbance  up  to  the  father  r  before  we  eliminate  an 
empty  tree.  Al.so,  to  avoid  deadlocks  some  of  the  ca.ses  2  6  need  a  splitting  into  subcases.  The 

pleasant  elTect  of  this  setting  is  that  the  number  of  nonzero  disturbances  never  increases  through 
a  rebalancing.  Kurthermore,  an  addition  or  deletion  elTects  at  most  one  disturbance.  Hence,  the 
number  of  nonzero  disturbances  is  never  greater  than  the  number  of  processes.  (Of  course,  the 
root  of  the  overall  tree  has  to  be  treated  individually,  since  here  the  disturbances  accumulate.) 

Applying  the  sequence  of  transformations  described  in  section  3  we  arrive  at  a  type  “multiiile  2-3- 
trcc”  specifying  the  operations  re_bal3Qce^(t)  which  repair  the  current  tree  fi.  Since  we  can  localize 
the  degenerated  tree  from  our  knowledge  of  its  lower  and  upper  bound  we  could  even  gener.ate  the 
necessary  tree  traversal  with  our  transform.ations.  Hut  this  is  not  reasonable,  for  the  search  would 
start  at  the  root  every  time  anew.  Yet,  we  know  that  the  only  new  degeneration  possibly  arising 
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from  the  repair  is  localized  at  the  father.  In  appendix  A  we  briefly  discuss  suitable  variants  of  the 
transformations  for  introducing  tree  traversal.  In  our  application  we  get 

axiom  V  ttree  t : 

F(t)=-  F(uD(subst(t.  rebalance  (current  (t))))  if  R(son  ,’(current(t))) 

- 1  otherwise 

where  R(s)  3  dist(s)  0  V  s  is  empty 

Finally,  to  show  deadlock-freedom  we  have  to  consider  the  possible  violations  of  those  restrictions 
that  refer  to  other  proces.ses.  Such  restrictions  only  occur  in  the  operation  subst  of  the  type 
MULTIPLE  TREE"*'.  Therefore  we  have  to  examine  all  ca.scs  of  the  operation  rebalance  with 
respect  to  these  requirements  of  subst.  The  only  critical  nodes  are  the  “higher”  .sons  of  r  (sec 
the  ligurcs  2  (i),  they  must  not  be  the  current  trees  of  other  processes.  l''or  downward  processes 

Add  and  Delete  there  is  no  problem:  they  are  not  restricted  in  any  way  and  thus  will 
eventually  move  on.  An  upward  process  —  repair  docs  not  conflict  with  r  either  and  therefore 
will  eventually  move  up  to  r  (where  an  arbitrary  number  of  processes  arc  permitted).  In  other 
words,  the  type  EXTENDED  MULTIPLE  TREE  has  the  invariant  property  that  that  there  is  at 
least  one  /i  for  which  no  re<|uiremcnt  is  violated. 


6.  Conclusion 

1'his  paper  exemplifies  the  typical  ap[)roach  that  is  taken  for  the  derivation  of  new  transformation 
rules.  One  considers  the  solution  of  a  special  problem  and  analyzes  it  carefully.  The  goal  of  this 
analysis  is  to  extract  the  essential  aspects  of  the  solution,  filtering  out  all  unimportant  details. 
The  second  step  is  to  put  this  extracted  knowledge  into  a  generalized  schematic  form  that  is 
mechanically  applicable.  The  final  step  has  been  omitted  here,  viz.  the  design  of  a  convenient  and 
precise  formalism  into  which  the  technical  details  can  be  cast. 

Such  a  schematic  and  formalized  tlcvelopment  has  an  important  side-effect:  Though  .sometimes 
looking  quite  intrinsic  and  complex  the  various  applicability  conditions  of  the  transformations  as 
well  as  certain  enrichments  of  types  indicate  what  is  actually  needed  to  perform  a  safe  development. 
These  proofs  are  necessary  to  guarantee  correctness  in  whatever  techni()ue  or  notation  they  arc 
carried  out.  b'ven  if  there  remains  a  lot  of  work  to  be  done  on  the  user’s  side,  the  transformations 
tell  him  at  least  which  problems  he  has  to  attack. 

The  future  research  on  this  subject  has  to  address  two  points  (and  probably  in  that  order):  First, 
it  is  necessary  to  study  other  special  type  transformations.  For  example,  how  do  the  rules  in  this 
paper  work  for  .systems  of  mutually  recur.sivc  type  declarations?  What  are  the  possibilities  if  we 
allow  infinite  objects  in  the  style  of  Dana  Scott?  Consider  the  system  of  equations 

u  -  cons(v,w),  v  cons(w,  u),  w=cons(u,v). 

The  fixpoint  of  these  equations  describes  the  doubly  linked  list 


The  transformations  for  pointer  implementations  apply  here  in  a  straightforward  manner.  Finally, 
how  do  other  types  that  are  not  recursive  declarations  fit  into  the  approa<  h?  Note  for  instance  that 


the  type  DICTIONARY  is  “almost”  recursively  describable  and  so  are  sequences,  queues,  stacks, 
etc. 

The  second  issue  is  to  back  the  transformations  more  rigorously  from  a  semantical  point  of  view. 
The  most  severe  problem  arises  here  in  connection  with  parallelism.  In  particular  the  pos.sible 
connections  between  abstract  data  types  and  concurrency  need  further  exploration.  Types  such 
as  MULTIPLE  TREE  allow  a  specification  of  the  overall  behavior  of  the  ensemble  of  processes  ac¬ 
cording  to  the  multiprogramming  assumption.  In  this  respect  the  universally  ((uantified  ecpiations 
and  restrictions  show  a  close  relationship  to  the  D-operator  of  temporal  logic  and  the  existential 
quantifiers  correspond  to  the  eventuality  operator  O.  When  these  connections  are  better  under¬ 
stood,  one  can  search  for  more  general  transformations  leading  from  such  global  specifications  to 
the  individual  protocols  of  the  processes  under  consideration. 
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Appendix 


This  appendix  addresses  a  few  points  that  were  too  lengthy  for  being  included  into  the  main  part 
of  the  paper.  Again  the  discussion  will  not  be  overly  formal. 


Appendix  A:  Nondeterminism  in  Abstract  Data  Types 

Nondeterminisrn  as  it  is  used  in  some  of  today’s  more  advanced  programming  languages  is  charac¬ 
terized  by  its  completely  “erratic”  nature.  This  means  in  the  first  place  that  one  cannot  predict 
the  result  of  a  computation.  Hut  in  addition  it  may  even  happen  that  two  executions  of  the  same 
expression  under  the  .same  circumstances  yield  different  results.  Within  the  classical  framework  of 
abstract  data  types  we  can  only  mirror  the  former  aspect,  the  latter  requires  an  extension  to  rela¬ 
tional  theories.  (Though  being  aware  of  this  gap  we  will  still  speak  of  nondeterminism  here.  After 
all,  we  only  want  to  apply  abstract  data  types  and  do  not  model  the  semantics  of  programming 
languages.)  This  limitation  even  has  its  advantages:  In  our  restricted  nondeterminism  we  arc  still 
allowc<l  to  use  an  ecpiation  such  as  x  =  e  to  substitute  x  by  the  expression  e  without  problems. 

'I'he  general  ca.se  of  the  transformation  in  section  3.2  is  ch.aracterized  as  follows:  We  are  given  an 
operation  f  together  with  a  restriction  R  of  its  domain  and  we  want  to  substitute  some  admissible 
subtree  s  of  a  given  tree  t  by  f(s).  Let  us  call  this  substitution  F(t).  Since  wc  must  not  apply  F 
unless  there  actually  exists  a  subtree  s  with  R(s),  the  axiom  roads 

V  tree  t :  ^3  tree  s  :  s  ^  t  A  R(s)^  =»  ^3  tree  s  :  s  ^  t  A  R(s)  A  F(t)  =-■  t[s  ^  f(s)] 

According  to  our  use  of  restrictions  we  can  split  this  up  into  an  axiom  and  a  restriction: 
axiom  V  tree  t :  3  tree  s  :  s  ^  t  A  R(s)  A  F(t)  t(s  <=  f(s)J 
required  V  tree  t :  3  tree  s  :  s  ^  t  A  R(s)  for  F(t) 

In  the  add-example  of  section  3.2  the  requirement  is  R(s)  =  s  is  leaf.  Since  there  always  exists  a 
subtree  s  of  t  fulfilling  this  requiremet  the  restriction  can  be  omitted. 

As  a  secotul  example  consider  the  definition 

delete(leaf(y),y)  empty  with  the  restriction  s  =  leaf(y)  for  delete(s,y) 

Here  the  restriction  determines  the  application  point  uni<]uely  and  therefore  we  g(>t  the  simplified 
version 

axiom  Vtree  t,  elem  y  :  Delete(t, y)  =  t(loaf(y)  «=  empty] 
required  V  tree  t,  elem  y  :  leaf  (y)  ^t  for  Delete(t,y) 

llemark:  This  example  .shows  that  it  will  be  useful  to  have  the  transformation  in  two  Il.avors.  In  one 
which  we  have  used  here  the  new  operation  F  is  undelinefl  if  there  does  not  exist  a  suitable 
subtree,  in  the  other  form  F  is  made  ifito  the  identity  in  that  ca.se. 

There  is  a  second  major  instance  of  nondeterinism:  Certain  operations  that  are  applic.ible  at  several 
points  in  the  structure  shall  be  executed  “as  often  as  possible”  but  in  arbitrary  order  (the  “demon” 
of  section  5).  The  order  of  applications  nuiy  decisively  irilluence  the  result,  in  particular  when  the 
operations  may  generate  new  application  points.  In  thi.s  case  wo  nmdify  the  previous  rule  such 
that  f  is  applied  repeatedly.  'I’he  axiom  then  reads 
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axiom  V  tree  t  :  B  tree  s  : 

s  ^  t  A  R(s)  a  F{t)  “  F(t[s  <=  f(s)]  if  3  tree  s  :  s  ^  t  A  R(s) 

F(t)  “  t  otherwise 

Note  that  F  now  is,  of  course,  the  identity  wlien  there  is  no  application  point. 

Tile  rebalancing  example  in  section  5  shows  the  need  for  a  generalized  variant  of  this  rule.  There 
a  process  should  not  treat  all  degenerations  but  only  those  that  were  reachable  for  it,  i.e.  those  on 
the  path  from  the  current  node  back  to  the  root.  This  leads  to  a  modification  of  the  transformation 
rule:  Assume  that  the  restriction  R  of  the  operation  f  is  of  the  form 

required  V  t :  R(son,(t))  for  f{t) 

Assume  further  that  f  may  establish  the  truth  of  R  on  its  result,  i.e.  R(soni(t))  may  cause  R(f(t)). 
Then  wo  simply  have  to  move  upwards.  In  this  case  F  is  defined  by 
axiom  V  ttree  t  : 

F(t)=  F(up(subst(t,f(current(t))))  if  R(son ,(current(t))) 
t  otherwise 


Appendix  B:  More  on  Pointer  Implementations 

This  part  of  the  appendix  describes  the  technical  derivation  of  the  pointer  implementation  of 
section  3.5  in  greater  detail  and  also  gives  a  brief  accent  on  the  underlying  model  that  justifies 
the  transformation.  The  transformation  probably  is  intuitively  clear  to  anyone  who  has  ever  done 
programming  with  pointer  structures.  But  if  we  want  to  do  better  than  referring  to  the  reader’s 
intuition  we  have  to  go  into  some  elementary  mathematics. 

A  finite  mapping  can  be  represented  by  a  finite  set  of  pairs.  If  we  u.se  pairs  of  the  forn\  (i,  x)  with 
i  t  index  and  x  C  contents  we  have  a  (terminal)  tno<lel  of  the  type  STORE,  'frees  arc  special 
graphs,  which  in  turn  can  be  repro.scntcd  by  mappings.  In  this  setting  the  operation  cons  (a,  b)  is 
implemented  by 

AWBli)  {{ni,(rA,ri,))} 

where  the  mappings  A  and  B  represent  the  trees  a  and  b,  1+)  is  the  “disjoint  tmion”  of  mappings  (all 
indices  of  B  are  consistently  renamed),  r^,  rg  arc  the  roots  of  A  and  B  and  ni  is  a  “new”  index. 
Consequently,  the  function  substitute(A, B,  C)  yields  a  new  mapping  A'  that  is  derived  from  A  by 
repl.acing  the  submapping  B  by  C  (obeying  the  possibly  ro(iuired  renaming  of  indices). 

An  efiiciency  rne.asure  suggests  itself.  Assume  that  A'  is  as  similar  to  A  as  po.ssible  (i.e.  the  indices 
are  accordingly  renamed).  Then  the  differences  D  -=  A  — (ADA')  and  D'  =  A'  — (AH A')  tell  us  how 
many  pairs  in  A  are  altered  or  ;id<le<l  to  achieve  A'.  In  the  following  constructions  the  sizes  of  D 
an<l  D'  depend  directly  on  the  length  of  the  given  expressions  (.and  not  on  the  sizes  of  A,  B  and  C). 
'fhereforc  the  cost  is  constant.  Con.sider  the  example  of  section  3.5: 

A'  -  substitute(A,  S,  U) 
where  S»-  cons(cons(A,  B),  C) 

-  A  W  B li)  C  111  {(ni,(ry4,rs))}  1+)  {(no,(n|,rc>))} 

U  -  cons(cons(A,L),  cons(B, C)) 

-  A  li)  LW  BW  Cli)  {(n.j,(r,A,rr,))}  W  {(n|,(r/i,rc))}  W  {(no,(ni,  nj))} 

L  ’  {(n;,,loaf(x))} 
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The  only  elements  not  in  ADA'  are 


{(ni ,  (r^,  ra»},  {(no,  (ni,  rc))} 

{(ns,  leaf{x))},  {(na,  (r^,  ri))),  {(ni,  (ra,  rc))},  {(no,  (n,,  ra))} 


Consequently,  it  suinccs  to  exchange  tlie  right-hand  sides  of  no  and  nj  and  to  add  the  pairs  for  n-a 
and  03. 

How  is  this  mechanized  in  a  purely  syntactic  fashion?  The  following  algorithm  derives  the  necessary 
information  by  inspecting  the  given  expression.  Since  the  tree  s  to  be  substituted  fretpjently  is  not 
given  in  the  cons(. . .)  form  we  reformul.ate  the  above  expression: 


t'  “  substitute(t ,  s,  cons(  cons(sonl(sonl(s)),  leaf(x)) ,  cons(son2  (sonl  (s)),  son2(s))  ) 


Hy  using  auxiliary  identifiers  this  reads 


10  "  s 

11  =■  sonl  (io)  “  sonl  (s) 
ia  =  son2(io)  son2(s) 

is  =  sonl(ii)  “  sonl  (sonl  (s)) 
i(  =  son2(ii)  =  son2(sonl  (s)) 


jo  “  cons(j,,j3) 
ji  =  cons(i3,j2) 
Ja  -  leaf(x) 

J3  -  cons(U,i2) 


The  above  detailization  follows  the  rules:  I5very  subtorm  of  the  kind  son,(. . .)  gets  its  own  idonl.ifier 
(corresponding  to  its  index  in  the  original  mapping).  ICvcry  cons(...)  and  leaf(. . .)  gets  an  index, 
too.  All  identifiers  i/,  of  the  left-hand  side  that  do  not  occur  on  the  right-hand  side  in  our  ca.se 
io  and  i]  can  be  replaced  by  the  corresponding  J^.  All  j„  not  covered  in  this  way  stand  for  new 
indices  in  our  case  Ja  an<l  Ja.  Translating  this  into  a  sequence  of  alter-expressions  of  the  type 
STOKIO  leads  to  the  program  of  section  3.5.  The  mechanical  nature  of  this  derivation  is  obvious. 
'I'lie  applicability  condition  is  that  the  expression  for  the  new  tree  u  can  be  expre.ssed  in  terms  of 
the  old  tree  s  and  leaf-operations. 

There  are  optimizations  possible.  Wor  example,  if  son2(sonl(5))  would  not  occur  in  the  expression 
for  the  new  tree  but  several  leaves  are  added  then  the  above  algorithm  a.ssigns  new  indices  (i.e. 
storage  locations)  to  many  of  the  leaves  without  noticing  that  all  indices  belonging  to  the  subtree 
son2  (sonl  (s))  are  available.  To  minimize  garbage  collection  more  elaborate  variants  are  therefore 
needed. 

Note  that  all  operations  in  the  paper  addition,  deletion,  rebalancing  -  meet  the  above  require¬ 
ments. 
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Api'endix  C:  Abstract  Data  Types  and  Locking 


In  section  3  we  have  :Mlopte<I  a  purely  fortiialistic  view  of  transformations  for  locks.  Now  we  will 
be  more  precise  and  also  st’idy  to  what  degree  abstract  data  types  can  be  used  and  where  the 
problems  arise. 

To  begin  with,  the  multiprogramming-assumptiur.  c  lains  parallelism  in  terms  of  sequential  inter¬ 
leaving;  If  there  arc  two  procc.sscs  P|  and  P2  issuing  .sequences  of  “atomic”  operations  a  a\  -  •  -Ok, 
T  =  Tj-  •  -Tm  then  the  semantics  of  their  concurrent  operation  is  explained  by  the  set  of  all  possible 
mergings  of  the  sequences  a  and  t.  This  set  is  called  shuffle  in  [12]. 

llemark:  Actually,  the  two  processes  generally  influence  each  other.  Therefore  one  has  to  model 
their  individual  behaviors  by  some  kind  of  formal  trees  and  the  shullle  h.as  to  be  generali/.cd  such 
that  it  merges  trees  into  sequences. 

Now  assume  that  wo  started  from  .a  program  where  the  operations  a  and  t  were  taken  to  be  atomic. 
The  shullle  of  this  program  therefore  is  the  set 

{oT,  to} 

If  a  and  t  arc  then  broken  up  into  sequences  of  more  elementary  operations  we  must  guarantee 
that  the  shullle  of  the  new  program  is  equivalent  to  the  set 

{<Tr  •  -tTfeTp  •  'Tm  .  I"!  -  •  ’  ’ff*}- 

On  the  other  hand,  the  .size  of  the  shuffle  imlicates  the  degree  of  concurrency.  One  safe  way  of 
increasing  that  size  is  enabled  if  the  operation  Tj  is  exchangeable  with  a,  i.e.  oti  =•  tjo.  Then  we 
get  the  equivalent  shullle 

{oi-  •  OfcTi-  •  -Tm  ,  TiOf  •  •<TfcT2-  •  -Tm  ,  Tr*  •  Ofe} 

Analogously  for  Tm,  <T\,  (t*  and  then  for  r^,  etc.  In  other  words,  we  have  to  identify  within  the 
seciuciicc  a  the  largest  subsecpience  that  does  not  allow  the  above  interchanging.  'Phis  le;uls  to 

a  =  ai-  •  ■ai-y[ai-  •  -  •  -Ok 

where  the  sequence  in  parantheses  is  a  critical  region  that  has  to  be  viewed  as  being  atomic. 

The  above  interchanging  is  in  particular  enabled  for  those  operations  Ui  that  are  the  identity  in 
the  given  semantic  interpretation.  In  the  sequel  we  will  treat  this  in  the  context  of  abstract  data 
types.  (For  shortening  the  writing-down  we  will  restrict  ourselves  to  one  kind  of  locks.) 


type  LOCK  (type  M)  declares  lock  .unlock  : 
enrich  M  by 

opns:  lock  :  name  x  m  — »  m 

unlock  :  name  x  m  — »  m 
locked  :  name  x  m  —*  bool 


axioms:  V  m  x,  name  fi,  tt  : 

locked  ^(lock  ^(x))  =  true 

locked  ^(lock„(x))  =  locked  ^(x)  if  fi  n 

locked^(unlock  ^(x))  =  false 

locked  ^(unlock  „(x))  *  locked  ^(x)  if  y,  ^  it 

locked  ^(f(x))  =  locked  ^(x)  for  all  operations  f  of  M 

locked ^(c)  =  false  for  all  constants  c  of  M 

f(lock  ^(x))  =  f(x)  for  all  operations  f  of  M 

f(unlock  ^(x))  “  f(x)  for  all  operations  f  of  M 

required;  V  m  x,  name  fi,  it  : 

-'locked^(x)  for  lock„(x)  if  it  ft 

end  of  type 

'Phis  type  specifies  the  essentials  of  locks.  Hut  it  has  its  problems:  A  minor  one  is  that  the  last  four 
axioms  are  jfc'iieric.  'I'hey  just  express  the  fads  that  the  basic  operations  of  Ihe  type  M  do  not  alter 
locks  and  that,  vice  versa,  locks  act  like  the  identity  on  all  operations.  This  is  exactly  what  we 
need  for  tin'  sc(|uences  occiirrint^  in  the  shullle.  Hut  the  .severe  probh-m  is  that  tlu'se  last  e<iuations 
.also  can  be  used  to  eliminate  any  lock  from  any  program  befor('  the  shullle  is  built.  1'hus  we  arc 
confronti'd  willi  the  situ.ation  that  we  need  ecpiations  to  specify  thc>  me.aniriK  of  cert.ain  operations 
but  th.at  w('  never  must  apply  these  equations  to  a  program.  In  other  words,  types  not  only  need 
hidden  functions  but  also  hirldcn  axioms. 

If  we  accept  the  above  ('x tension  of  the  type  mechanism  we  have  a  v.al liable  tool  that  maki's  the 
“underlining''  of  section  .'1.8  more  accurate.  I'br  particularly  chosen  functions  such  as  up  and  down 
we  may  add  the  eipiations 

down  (lock  (t))  “  lock  (unlock  (down  (lock  (t)))) 

unlock  (down  (t))  -  unlock  (down  (lock  (unlock  (t)))) 

Now  we  can  do  the  s.ime  development  that  we  have  <lone  for  the  procedure  Add*  in  section  .'1.8, 
but  in  the  applicative  style  of  abstract  d.at.a  types.  The  operation  Add'  with  the  initial  donnition 

Add'(t,x)  -  unlock  (Add  (lock  (t),  x)) 

then  gets  the  derived  specification 

Add'(t,  x)"  Add '(unlock  (down  (lock  (t))),  x)  if  lock  (t)  is  cons 
-■  unlock  (add(lock  (t),  x))  otherwise 

The  advantage  of  this  more  formal  treatment  is  that  we  can  state  more  precisely  where  read-  and 
write-locks  will  occur,  for  example 

down  (w-lock  (t))  --  w-lock  (r-unlock  (down  (r-lock  (t)))) 

rebalance(w-lock  (t))  =  w-lock  (w-unlock  (rebalance(w-lock  (t)))) 

The  intrinsi(  [)robi''m  remains,  of  course,  to  determine  which  operations  allow  the  addition  of  such 
ec|iiations.  t’or  the  operations  such  as  up  and  down  this  is  done  as  a  byproduct  of  the  earlier 
t  ransformation  rules.  I'or  other  oper.ations  such  .as  rebalance  the  user  has  to  provide  a  proof  e.g. 
th.at.  the  operation  is  the  identity  in  a  suitably  chosen  erpiivalence  relation.  In  .addition,  it  must 
be  cl.arilied  whether  a  ri-ad-  or  a  write-lock  is  needed.  The  remaining  details  Hu  n  .are  of  a  purely 
mechanic  nature  such  that  we  could  le.ave  them  to  a  transformation  rule  INTIIODUCK-I-OCKS. 
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